Better branding of -betterC

IGotD- nise at nise.com
Tue Nov 3 10:25:15 UTC 2020


On Tuesday, 3 November 2020 at 06:04:26 UTC, norm wrote:
>
> Just going to pick on this para. sorry :)
>
> I hear this a lot and it is simply not true. Working in 
> embedded for the last ~18yrs (automotive and medical) every 
> project since 2010 I know of is C++. At conferences and the 
> like over the last 2-3yrs there is a lot of talk about Rust and 
> people are starting to mention MicroPython for prototyping. But 
> as a whole everyone I talk to is looking forward to upgrading 
> their C++ compilers on the next project to get C++20 features.
>
> Every C++ embedded project I have ever seen has exceptions 
> turned off.

It's funny that they talk about C++20 in the embedded environment 
but many features cannot be used because of STL. STL is just like 
phobos and will become just as big if you statically link with 
it. Turning exceptions off also means that many parts of the STL 
library will be dysfunctional. Usually you need specialized 
libraries.

Modern C++ is even more of a mess because they have moved much of 
the functionality to the STL library. std::move for example is a 
library template, which can be duplicated outside of course but 
still you need to do that with a lot of functions. Even 
statically compiled primitives are library templates today with 
some inunderstandable implementation underneath. STL is this big 
blob that can include all sort of things that you don't expect 
even for simple primitives.

Apart of a the ugliness of modern C++, many of the modern 
features are implemented in such a way it is difficult to make it 
freestanding from STL. You do not want STL in embedded systems.

Is modern C++ good for embedded systems? No, you need to slice of 
half of the new features because of the reasons I mentioned above.



More information about the Digitalmars-d mailing list