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