Reasoning
In doing this project a couple of decisions were made that influence the result, this page will try to describe these.
Use avr-gcc as target platform
This is perhaps the most important factor of this project. The reason is that is is to scratch my own itch. When the avr-toolchain is downloaded there is generally C++ support, but no library support what so ever. Not even the quite miniscule freestanding C++ standard is supported.
In order to have the basic functionality of the C++ library I started this project after hearing Ben Craig, the author of the freestanding proposal speak at emBO++ in 2018 ( youtube link:Standardizing an OS-less subset of C++ ).
Create as faithful an implementation as possible
If the project is to have any impact on the future of standardisation, the implementation must be as close to what is proposed as possible. Since the target is the AVR, even though there is no floating point unit on the chips, floating point operations are possible, however the floating point arithmetic functionality has been left out as per the proposal as well as functions (also mainly floating point) that touch errno.
One could consider adding this back in using a flag, however I find that this approach gives a more correct user experience, which is what is wanted in an implementation of a proposal.
Don't write new code
The idea of using gcc as the basis for the implementation instead of writing the whole thing from the bottom up is that it has been mentioned numerous times that one should use the standard library rather than write the same algorithms again, poorly. By using an existing implementation new features are also added "for free" that would otherwise be hand-coded from the bottom up.
This leads to the corollary that the only changes that should be made is what parts of the existing library that should be #ifdef
'd in.