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
What about constexpr? #58
Comments
Marking this as a future issue for now. Apparently not everyone thinks P0202 is a good idea as is (can't remember where I read that, but I definitely did), and too many existing parts of the standard library would have to be implemented again in order to be usable at compile-time. Some of them even rely on |
C++20 is approaching with plenty of extended
All those improvements should make C++20 the suitable candidate for making most of the library |
Another advantage I hadn't thought of is that undefined behaviour isn't allowed when invoking Both compile-time checks and runtime checks are interesting though (just to make sure that all the tests are run even when there are failures at compile time), so I would most likely just add another CI job per compiler for compile-time tests, and define |
Instead of completely waiting for C++20, I decided to start rolling out some |
In the spirit of a few messages above, 1.13.0 ships with a new CMake option called The |
Changing the whole test suite would be quite the task and I still don't have a master plan for it, so for now I decided to go with the simplest approach: have a new test where List of sorters to try to make
Adapters:
Measures of presortedness:
Other actions:
I will first perform tests on the |
Components that can reasonably be marked
|
Standard
constexpr
algorithmsP0202 proposes to add
constepxr
to many functions from<cstring>
and to basically every algorithm from<algorithm>
. Apparently, the proposal was rather well-received and we might haveconstexpr
algorithms in the standard at some point in the future.So, what about cpp-sort? Since we're already using C++14, we can use the improved
constexpr
but I feel that it won't solve every problem:std::swap
and a few other utility functions are notconstexpr
, but we could probably reimplement a few of them. Update: actually, some parts of<functional>
such asstd::mem_fn
and a good part of<iterator>
would have to be reimplemented too in order to handle everything, and some parts are rather huge.constexpr
either, but since we ship altered versions of many of them, addingconstexpr
shouldn't be a problem.constexpr
version of the standard algorithms such as Bolero Murakami's Sprout don't use algorithms that allocate heap memory; these projects are generally only meant to be used at compile-time.I would be trivial to change some algorithms to be
constexpr
but it's probably not the case for most of them. A partialconstexpr
support could be a starting point.The first revision of P0202 takes several design choices into consideration and gives the following set of rules to make standard algorithms
constexpr
(<cstring>
has been disqualified fromconstexpr
enhancements):constexpr
should be enough.std::memcpy
and friends, so compilers are encouraged to use their own equivalentconstexpr
intrinsics of these functions instead. It concerns everything that relies on thestd::copy
andstd::move
family of algorithms.std::stable_partition
andstd::stable_sort
are not markedconstexpr
.Basically, we will wait for a
constexpr
-ified standard library (at least forstd::copy
andstd::move
), then we can start toconstexpr
-ify cpp-sort. The wholeiter_move
thing might make things harder to do though. Anyway, this is definitely a future issue.Use cases
I often wondered whether there were use cases for
constexpr
sorting algorithms. Here is a list of situations where sorting at compile-time might be useful:std::set
which sorts its input and performs a binary search on lookup, which is more performant than the tree implementation (e.g. Frozen).The text was updated successfully, but these errors were encountered: