New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
P0100: Comparison in C++ #18
Comments
This was tagged as a future issue since it assumed that the work would be too big without a standard implementation. Actually reimplementing what was thoroughly described in the proposal was a matter of hours. This is still a huge piece of work, especially adapting the algorithms and providing the right tools to users, but we don't have to wait for C++19 or C++20 to start implementing it. Update: on the other hand, I realize that I am not sure how P0100 plans to handle algorithms and this is a bit troubling. I'm tempted to add the future label back. |
Implement The |
Not sure what to do with that issue anymore: half of the problems are solved with the new C++20 I'm keeping the issue open for now but probably won't implement the features as proposed. |
This issue has been surperseded by #145 which restates the challenges of adapting the library to three-way comparison with the tools we're getting in C++20. |
P0100, Comparison in C++, is a proposal to enhance comparisons in C++, which may directly affect sorting algorithms and related features. Among the future improvements are the following ones:
Since cpp-sort is all about sorting, these ideas may be interesting to improve the library. That said, I don't want to change anything before an actual design is proposed to alter the algorithms in the standard library to handle three-way comparators. Once such a design has been proposed and validated, I'll start updating cpp-sort so that it matches the new design.
Among the changes proposed or implied by P0100, here is what could be used to improve cpp-sort, and a bunch of interesting questions:
std::qsort
(mostly used to show how other algorithms are better though).not compare(x, y)
used to either make sorts stable or make them more efficient with equivalent values.grail_sort
already uses some kind of three-way comparator, but one that almost always perform more operations than it should. Standard three-way comparators would be better for sure.total_order
, if possible so that the results are a bit more deterministic?total_order
).Lots of things to think through, but it may be interesting in the end :)
As always, here we go with a list of features to implement:
partial_ordering
,weak_ordering
andtotal_ordering
.partial_order
,weak_order
andtotal_order
.partial_less
,partial_unordered
,partial_greater
,weak_less
,weak_equivalence
,weak_greater
,total_less
,total_equal
andtotal_greater
.std::string::compare
.three_way_compare
so that it can adapt both binary and trinary comparators. Make it take an order and 4 functions objects corresponding to<
,>
,<=
and>=
, which could possibly be optimized. If these function objects are not provided by the user, default them to generic function generating the comparison from the order function.three_way_compare
and transform everything with it).bubble_sorter
example (it might get tricky).The text was updated successfully, but these errors were encountered: