Details
- Reviewers
jdoerfert philnik ldionne huixie90 - Group Reviewers
Restricted Project - Commits
- rG23c7328bad92: [libc++][ranges] Implement `ranges::nth_element`.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libcxx/include/__algorithm/nth_element.h | ||
---|---|---|
40 | The ABI annotation was missing. |
libcxx/include/__algorithm/nth_element.h | ||
---|---|---|
28 | Could you do the whitespace formatting in a different patch? | |
libcxx/include/__algorithm/ranges_nth_element.h | ||
47 | ||
libcxx/test/std/algorithms/alg.sorting/alg.nth.element/ranges_nth_element.pass.cpp | ||
73 | I don't think we should do that. It's quite fragile and we even have _LIBCPP_DEBUG_RANDOMIZE_RANGE to avoid that users depend on the exact output. | |
147 | ||
196 | Descending? | |
247 | I don't think this should be here. | |
276 | Also this. |
All in all, LGTM with some comments.
You should poke the CI.
libcxx/include/__algorithm/nth_element.h | ||
---|---|---|
28 | +1, it'll make it possible to ignore it for git blame. We should really strive to do these mostly-whitespace changes in NFC patches, otherwise we'll destroy our ability to git blame, and we'll pay for that in the future. | |
libcxx/test/std/algorithms/alg.sorting/alg.nth.element/ranges_nth_element.pass.cpp | ||
73 | I agree. I think this is going to be brittle if we make changes to our algorithms. Also, if you remove this, you can (and should) still check that the value of the nth element is as expected (i.e. instead of passing an expected array, you can pass an expected value (or iterator to validate the position)). | |
165–169 | IMO this is a bit complicated, we could instead just manually call test_all_cases with each (input, n, expected) combination. And that would allow getting rid of the array<array<...>> overload of test_all_cases, which I had to pause quite a bit on. | |
215 | Instead of having multiple test_iterator_n functions, I would do something like this (IMO it localizes things which makes it more obvious where they are used): constexpr void test_iterators() { auto check = []<class Iter, class Sent> { // all checks }; check.operator()<random_access_iterator<int*>, random_access_iterator<int*>>(); check.operator()<random_access_iterator<int*>, sentinel_wrapper<random_access_iterator<int*>>>(); // etc. } If you dislike the lambda, you could define it as a function template named e.g. test_iterators_impl, but the point here is to make it obvious that it's only an implementation detail of test_iterators. Otherwise, I'd have to check whether test_iterators_1 is somehow called from elsewhere in the file, and whether that might be the reason for giving it a "global" name. |
Address feedback.
libcxx/include/__algorithm/nth_element.h | ||
---|---|---|
76 | Thanks a lot for finding this issue! Will fix in a follow-up. | |
159 | Same as the other comment -- will fix in a follow-up. | |
libcxx/test/std/algorithms/alg.sorting/alg.nth.element/ranges_nth_element.pass.cpp | ||
73 | Thanks, this makes the tests way less verbose. Rather than passing values explicitly, it seems easier to create a copy of the input and sort it, then compare the nth elements between the partially-sorted and fully-sorted sequences. | |
165–169 | (no longer applies now that we're not checking for the exact output) | |
247 | Same as the other review -- this is necessary to compare the value of the nth element. | |
276 | (see the other comment) |
- Don't randomize the range if nth == last -- otherwise, the function isn't a no-op;
- rebase on main.
libcxx/include/__algorithm/nth_element.h | ||
---|---|---|
238 | I think this condition is necessary -- otherwise, the function isn't a no-op when __nth == __last. The standard doesn't say it should be a no-op explicitly, but nevertheless, it seems strange to have a call to nth_element(vector.begin(), vector.end(), vector.end()); reshuffle the vector. |
libcxx/include/__algorithm/nth_element.h | ||
---|---|---|
242 | question: why do we need inline in these function templates? |
Could you do the whitespace formatting in a different patch?