About everything in std::initializer_list is noexcept, and builtin wrappers (type traits, bit_cast etc etc.) are 0-cost.
You shouldn't try to avoid all of the stdlib, but rather vet what you use from it. Furthermore, stuff like LTO or -ffunction-sections -fdata-sections (+ --gc-section when linking) gets rid of unused symbols, as long as your toolchain provider compiles the C stdlib and C++ stdlib with these
> coroutines
Almost everything is customizable by user (including class-scoped operator new), is it not?
> Where should embedded c++ projects go now that they are not welcome anymore?
C++ is still very much suitable for embedded, and while I disagree with most of your post I agree that: 1) there should be a linker flag to wrap all std:: exceptions instead of using -Wl,-wrap for each individual exception when needed and 2) that embedded feels like a second-class citizen sometimes ("deprecating volatile" (reverted), #embed missing C++23 etc)
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)