Thank you! It is nice to see that others keep trying and using C++ for embedded. As to 'vetting' the use of std library — I do not see how to do it without making a fork (or writing own "stripped down" version from scratch). E.g., you cannot simply decide not to use container allocator parameters, to reduce symbol sizes.
The point I tried to make is that you cannot reasonably use modern features of C++ with your own standard library — the amount of undocumented internal compiler details you have to guess and match exactly is becoming unmanageable. And while -fno-rtti and -fno-exceptions still miraculously are supported by compilers (it is explicitly non-conforming C++ even in "freestanding" implementation, according to 16.4.2.5) and stop compiler from emitting references to std::, other features like allocators do not have an "off" switch.
The initializer_list is a good example. N4950 17.10 explicitly tells you there are multiple valid ways to implement it. If you guess incorrectly, your program will crash.
So current C++ standard library must be treated like part of the compiler implementation. It did not use to be like that.
> As to 'vetting' the use of std library — I do not see how to do it without making a fork (or writing own "stripped down" version from scratch). E.g., you cannot simply decide not to use container allocator parameters, to reduce symbol sizes.
Yes, correct, what I meant is that you can still use many features like type_traits, bit_cast, initializer_list, span, array etc. Of course, std::string and friends are a bit no-no in very memory constrained cases.
> So current C++ standard library must be treated like part of the compiler implementation.
Indeed. Though even in C, compiler will assume C standard library is present unless you explicitly tell it not to (it optimizes calls to memcpy and will emit memset calls when initializing variables to 0)