P0829 and freestanding implementations
P0829 proposes to update the requirements for freestanding implmentations of the C++ standard, with notably a plea to make most of the header <algorithm> available to those implementations. Since cpp-sort mostly provides algorithms, it would be interesting to make most of it available for freestanding implementations too once the committee agrees in what should be available. We could introduce a simple CPPSORT_FREESTANDING switch to require that cpp-sort builds with freestanding implementations.
A few things wouldn't be available anyway:
- A few algorithms such a
merge_sortallocate dynamic memory: those should either be excluded or be made to fallback to non-allocating versions, which might still be desirable. It would be a good reason to replace the deprecatedstd::get_temporary_bufferby a safer custom solution that would simply returnnullptrin freestanding mode. - Algorithms specifically dealing with floating point should be excluded because freestanding implementations wouldn't be required to support floating point types.
- The evolutions proposed in #22 wouldn't be available since they would rely on threads and standard execution policies.
- A few math functions might have to be replaced by hand since most of them can set the
thread_localvariablestd::errno.
On the other hand, we could introduce more compile time switches through macros to have more granularity: no floating point numbers, no memory allocation, no threads, etc...
I will keep track of the progress of P0829 and probably start working when the committee starts to get close to a new specification for freestanding implementations.
Just a note that if accepted someday, P0709 - Zero-overhead deterministic exceptions: Throwing values will most likely change the landscape when it comes to exceptions. The discussion about whether out-of-memory should be treated as an exception is yet another debate but shouldn't change the fact that heap-allocating algorithms would probably be banned in a freestanding implementation.
A simple solution that could be in scope for the library one is a library solution: adding a page to the documentation listing the features that are potentially missing in freestanding implementations, and which components of the library would be affected. Such a list could also easily be used as a TODO list for future improvements.