Oh noes, the binding of internal compiler state to STL will become even more severe with this. It started slowly. You needed exact magic std::initializer_list definition in your headers to match the code generated by the compiler, or the program would crash. RTTI (that was of little use to programs that tried to avoid standard library) Now there are coroutines and this thing. I feel like it is bye-bye to the completely non-standard compliant practice of using C++ without all the standard library. Where should embedded c++ projects go now that they are not welcome anymore?
> Where should embedded c++ projects go now that they are not welcome anymore?
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
The std::meta stuff are only ever running at compile time, so I don't think this would actually interfere much?
now that a lot of std:: is constexpr, who knows how much of it will get pulled into compile time by std::meta stuff (I do not. I am asking). I know of no way of using different std libraries, one for compile time and one for target. Meaning, using this c++ variant without std library shipped with the compiler just got even impossiblier.
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)
It's not that hard to just copy the relevant part from the standard library of your platform