[libcxx-commits] [PATCH] D149830: [libc++][ranges] Implement the changes to node-based containers from P1206 (`ranges::to`):
Louis Dionne via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Fri Jul 7 13:32:35 PDT 2023
ldionne requested changes to this revision.
ldionne added a comment.
This revision now requires changes to proceed.
Thanks! I don't have a lot of comments, the patch is quite large but there's a lot of mechanical changes that don't differ from class to class, which makes this easier to review.
================
Comment at: libcxx/include/list:786-788
+ for (auto&& __e : __range) {
+ __emplace_back(std::forward<decltype(__e)>(__e));
+ }
----------------
Maybe we can use `prepend_range(...)` here instead? It would make it the same as what we do for `forward_list`.
================
Comment at: libcxx/include/list:920
+ void append_range(_Range&& __range) {
+ insert_range(end(), std::forward<_Range>(__range));
+ }
----------------
IDK if you should be using `insert(...)` here. However, either all of these new methods should lower to `insert(...)`, or none of them should (and then they should probably be for loops with `emplace_foo(...)`).
================
Comment at: libcxx/include/map:1125
+ : __tree_(__vc(__comp), typename __base::allocator_type(__a)) {
+ insert_range(std::forward<_Range>(__range));
+ }
----------------
`__tree` also has `__assign_unique(_ForwardIterator, _ForwardIterator);` available, I'm wondering whether that should be used instead. I think we have some benchmarks for `std::map`, it would be worth adding some simple benchmark for the `from_range` constructor and checking which approach is fastest.
================
Comment at: libcxx/include/unordered_map:1643
+#if _LIBCPP_STD_VER >= 23
+template <ranges::input_range _Range,
+ class _Hash = hash<__range_key_type<_Range>>,
----------------
Can you validate whether you tested these `enable_if`s in your deduction guide test? I think you want to add that stuff to `AssociativeContainerDeductionGuidesSfinaeAway`.
================
Comment at: libcxx/test/std/containers/associative/from_range_associative_containers.h:27
+template <class Container, class Range>
+concept HasFromRangeCtr = requires (Range&& range) {
+ Container(std::from_range, std::forward<Range>(range));
----------------
This concept doesn't seem to cover ctors of the form `map(from_range_t, R&& rg, const Allocator& a))`. Only those that specify the comparator.
================
Comment at: libcxx/test/std/containers/associative/from_range_associative_containers.h:171
+template <class Container, class Range>
+concept SetHasFromRangeCtr = requires (Range&& range) {
+ Container(std::from_range, std::forward<Range>(range));
----------------
Same comment as above.
================
Comment at: libcxx/test/std/containers/associative/multiset/multiset.cons/from_range.pass.cpp:18
+
+// template<container-compatible-range<value_type> R>
+// multiset(from_range_t, R&& rg, const Compare& comp = Compare(), const Allocator& = Allocator()); // C++23
----------------
Uber-nitpick but we generally try to have the synopsis comment above the includes. Applies here and elsewhere.
================
Comment at: libcxx/test/std/containers/insert_range_maps_sets.h:253
+
+ { // Full container.
+ // full_c.insert_range(empty_range)
----------------
Or something similar? Full has a connotation that we don't want to have here. It kinda implies "no more capacity", to steal your words. `FullContainer` & friends should also change accordingly.
================
Comment at: libcxx/test/std/containers/unord/unord.set/unord.set.cnstr/deduct.pass.cpp:260-264
+ // FIXME -- the constructor doesn't seem to exist.
+ { // (from_range, range, alloc)
+ //std::unordered_set c(std::from_range, Range(), Alloc());
+ //static_assert(std::is_same_v<decltype(c), std::unordered_set<int, DefaultHash, DefaultPred, Alloc>>);
+ }
----------------
If this is true, this would need a LWG issue. We can add it as a comment here.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D149830/new/
https://reviews.llvm.org/D149830
More information about the libcxx-commits
mailing list