I'm just using all of this on embedded platforms without issues - and can't wait to use reflection there either, it'll be ultra useful for ESP32 and Teensy projects we're working on
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)
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.
There was the C standard library that could be consumed by C++ applications, the C++ frameworks specific to each compiler vendor that sadly are no longer a thing, and the C++ ARM de facto standard with only iostreams, being used as the initial discussion for what would become C++98, a decade later.
Many of C++ warts are related to this historical evolution, like how many variations of string, arrays and other collection classes do you want to use in a single project?
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)
C++23 is not abandoning embedded. Instead there is a tonne of misinformation around that is confusing people. You can easily tell what parts of the STD is available by looking up the concept of Freestanding, which is a legitimate part of the c++ standard which tells you what is absolutely safe to use in embedded. Usually some of the non-freestanding stuff is also safe to use.
Then what you do is add support for the ETL (github.com/ETLCPP/) which will help you by offering STD like classes for the parts that are not safe to use or just give you the std class wrapped in their namespace.
What we do is turn off RTTI and for now exceptions (most compilers let you do that with ease but we are looking at maybe using them in the future because of recent research indicating it would be possible and save us binary size at the same time) and you lean heavily into the constexpr side of things because anything you can get the compiler that is running nightly or on your PC to do rather than on the embedded system is just fine. We do not use coroutines so there I have no opinion.
Personally I am looking forward to the Reflection stuff because it is all compile time (and no that does not mean that your std on your pc somehow leaks illegal functions into your code constexpr/consteval is embedded safe) and it will allow me to make code that will be easier to debug than the recursive template expansions are now (stepping through a recursion is bad even if we strictly limit the depth of them but reflection will allow me to do an expansion into a flat set of ifs instead).
Yes, compilers support turning off exceptions and RTTI, for a long time now. C++ language does not. They could have supported it, but have chosen to explicitly not, as seen in the above section from the standard.
Nothing the committee does seem to support embedded. I will be glad to be shown I'm wrong.
Imagine Linux devs would start worrying about what "C standard" wants xD.
In my industry (gamedev), folks never needed to worry about how non-standard our code is either. As long as it ships on relevant half-dozen platforms and gets job done, its fine. One does not get a Boy scout badge for being standard compliant.