Allow absl/algorithm/container.h in DEPS

17 views
Skip to first unread message

Andrew Rayskiy

unread,
Apr 4, 2022, 9:38:39 AMApr 4
to cxx
Hi all,

From what I see in DEPS, only optional/variant/int128 includes from absl are allowed. What about expanding this with container.h? I find these container functions pretty useful and much cleaner than their regular std counterparts. 

-- Andrew

Kyle Charbonneau

unread,
Apr 4, 2022, 10:04:37 AMApr 4
to Andrew Rayskiy, cxx
It looks like absl/algorithm/container.h is mostly STL algorithms that take a container, absl::c_sort(c), rather than two iterators, std::sort(c.begin(), c.end()). That overlaps pretty substantially with std::ranges algorithms. std::ranges is C++20 but Chrome has implemented most of it in base/ranges/algorithm.h, so the equivalent to absl::c_sort(c) would be base::ranges::sort(c).

Ideally we wouldn't allow another new set of container algorithms.

Kyle

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/6349830f-0335-47dd-8384-db93155ea4b0n%40chromium.org.

Andrew Rayskiy

unread,
Apr 4, 2022, 10:22:58 AMApr 4
to cxx, kyle...@chromium.org, cxx, Andrew Rayskiy
base::ranges lack container versions of numeric algorithms -- in particular c_iota, c_accumulate and c_partial_sum. 

K. Moon

unread,
Apr 4, 2022, 11:07:27 AMApr 4
to Andrew Rayskiy, cxx, kyle...@chromium.org
I think the argument that we should standardize on what C++20 will provide in the future, rather than what Abseil provides now, is persuasive. Most of these implementations seem to be fairly thin wrappers anyway, so not having two ways to do the same thing seems better to me.

Reply all
Reply to author
Forward
0 new messages