[libcxx-commits] [PATCH] D127834: [libc++][ranges] Implement `ranges::stable_sort`.

[Konstantin Varlamov via Phabricator via libcxx-commits]

var-const added inline comments.


================
Comment at: libcxx/include/__algorithm/ranges_stable_sort.h:39
+  template <class _Iter, class _Sent, class _Comp, class _Proj>
+  _LIBCPP_HIDE_FROM_ABI constexpr
+  _Iter __stable_sort_fn_impl(_Iter __first, _Sent __last, _Comp& __comp, _Proj& __proj) const {
----------------
Mordante wrote:
> Please remove the `constexpr`
Thanks!


================
Comment at: libcxx/test/std/algorithms/alg.sorting/alg.sort/stable.sort/ranges.stable.sort.pass.cpp:139
+      V{10, 101}, {12, 121}, {3, 31}, {5, 51}, {3, 32}, {3, 33}, {11, 111}, {12, 122}, {4, 41}, {4, 42}, {4, 43},
+      {1, 11}, {6, 61}, {3, 34}, {10, 102}, {8, 81}, {12, 123}, {1, 12}, {1, 13}, {5, 52}
+    };
----------------
Mordante wrote:
> I would suggest to make the `original_order` member a simple integer sequence: 1, 2, 3, etc. That makes it easier to verify whether the output is correct. Identical values will have incrementing values.
I started with that, but then I had the idea of enumerating each duplicate value instead (read those `31`, `32`, `33` as `3.1`, `3.2`, `3.3`, etc.). I think it makes it more readable because following the numbering within a duplicate is much easier than following the numbering across all the elements. What do you think?


================
Comment at: libcxx/test/std/algorithms/alg.sorting/alg.sort/stable.sort/ranges.stable.sort.pass.cpp:150
+      {11, 111},
+      {12, 121}, {12, 122}, {12, 123},
+    };
----------------
Mordante wrote:
> Is the trailing comma allowed?
Yes. Removed it for redundancy.


================
Comment at: libcxx/test/std/algorithms/alg.sorting/alg.sort/stable.sort/ranges.stable.sort.pass.cpp:168
+
+  { // A custom comparator works.
+    {
----------------
Mordante wrote:
> It would be good to validate stability in these tests too.
To clarify, do you mean all the tests in `test()`? Or just the tests with a custom comparator?


================
Comment at: libcxx/test/std/algorithms/alg.sorting/alg.sort/stable.sort/ranges.stable.sort.pass.cpp:246
+  }
+
+  { // `std::ranges::dangling` is returned.
----------------
Mordante wrote:
> Here we can validate complexity. Obviously implementations can make different choices regarding when there's not "enough extra memory" but we can test the N log (N) for a small number of items.
Similar to the `sort` patch, I don't think we have a great way of doing this:

- we can use the exact number of operations our implementation happens to perform (we have some precedent in e.g. `test/libcxx/algorithms/alg.sorting/alg.heap.operations/make.heap/complexity.pass.cpp`), but that would make it libc++-specific and, IMO, has limited usefulness;
- simply testing for `num_operations < N*log(N)` isn't going to work because it's actually `k*N*log(N)`, where `k` is an arbitrary constant;
- the "proper" way would be to test with increasingly large inputs and applying some math to calculate the growth factor, but that seems like a sizable project in itself, even assuming it's worth the implementation effort.



================
Comment at: libcxx/test/std/algorithms/alg.sorting/alg.sort/stable.sort/ranges.stable.sort.pass.cpp:255
+  test();
+  // Note: `stable_sort` is not `constexpr`.
+
----------------
Mordante wrote:
> Interesting since it's possible to allocate memory in `constexpr` functions.
I know that [[ http://wg21.link/p0202 | P0202 ]] was adding `constexpr` to algorithms. At the time (in 2017), making `stable_sort` `constexpr` was infeasible:

> Algorithms `stable_partition`, `inplace_merge` and `stable_sort` allocate memory, construct variables using placement new, use `unique_ptr` and do other things not acceptable in constexpr expressions. Making those algorithms constexpr seems to be a hard task that would require a lot of intrinsics. Those algorithms are not marked with constexpr in this wording.

I don't know if there's been any work in that direction since then. Perhaps it's ripe for a new paper?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127834/new/

https://reviews.llvm.org/D127834