[libcxx-commits] [PATCH] D130070: [libc++][ranges] Implement `std::ranges::partition_{point, copy}`.
Konstantin Varlamov via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Tue Jul 19 02:39:55 PDT 2022
var-const added inline comments.
================
Comment at: libcxx/include/__algorithm/ranges_partition_copy.h:43
+ _LIBCPP_HIDE_FROM_ABI constexpr
+ static partition_copy_result<_InIter, _OutIter1, _OutIter2> __partition_copy_fn_impl(
+ _InIter&& __first, _Sent&& __last, _OutIter1&& __out_true, _OutIter2&& __out_false,
----------------
These two algorithms seem borderline when choosing whether to delegate or reimplement. I'm quite open to delegate if you feel it would be beneficial.
================
Comment at: libcxx/test/std/algorithms/alg.modifying.operations/alg.partitions/ranges_partition_copy.pass.cpp:198
+ test_iterators_in_sent_out1_out2<InIter, Sent, Out1, cpp20_output_iterator<int*>>();
+ //test_iterators_in_sent_out1_out2<InIter, Sent, Out1, random_access_iterator<int*>>();
+ //test_iterators_in_sent_out1_out2<InIter, Sent, Out1, contiguous_iterator<int*>>();
----------------
I am concerned about the combinatorial explosion here. Perhaps it is sufficient to test with just the weakest and the "strongest" iterator types that satisfy the necessary constraints?
(Note that I think `partition_copy` is the only algorithm to have two different output iterator types)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D130070/new/
https://reviews.llvm.org/D130070
More information about the libcxx-commits
mailing list