C++ is a mess but it's one of the few languages that gives you low-level control of memory and fast code with zero or near zero cost abstractions. So for a certain class of application it's still the best choice. Music software, for example, is pretty much exclusively written in C++. I don't enjoy C++ the language very much but you can build some very cool things with it.
Personally I'm hoping Rust displaces it from most of these remaining niches but even if it does it will probably happen slowly.
> it's one of the few languages that gives you low-level control of memory and fast code with zero or near zero cost abstractions. So for a certain class of application it's still the best choice.
For a certain class of program, you mean. For applications specifically, the advantages you mention are barely relevant. Usually only small parts of a whole application need low-level control of memory etc. Those can be written in C, with the rest written in a cleaner higher-level language that interfaces easily with C (there are many such)
C++ is proof that a single language can't satisfy all needs. It tries to do the low-level stuff as well as C, and fails because it can't produce libraries that are as easy to link to. Then it tries to do all the high-level stuff as well as other languages, and utterly fails because it can't get away from its low-level roots. D, Rust, and Nim all make better compromises that suit just about all C++ use cases. Go and Pony do a better job for some but not others. I won't say there's no room for C++ in a sane computing world, but its legitimate niche is very small indeed.
>For a certain class of program, you mean. For applications specifically, the advantages you mention are barely relevant. Usually only small parts of a whole application need low-level control of memory etc.
I'd say Rust has a similar level of control. I just rewrote our longest build step (37 minutes on a normal build) in Rust. By having control over when things are allocated I could get it down to about 20 seconds. The previous software is written in Java.
If you want speed you need to choose C, C++ or Rust. If you want it safely, then Rust. I'd argue in my case that Rust was probably the fastest choice. As I probably would have copied more in C/C++. In Rust I can trust that my memory is intact.
I'd also choose C over C++ though. I find it's a much more manageable language. I never found it hard to make the right abstractions in it, except for maybe a lack of generics (which C11 kind of solves for).
I got introduced to C++ via Turbo C++ 1.0 for MS-DOS, in 1993.
So if it was good enough for 640 KB max, with 64KB executables, it shouldn't be an issue in most micro-controllers, but the biggest issue is the existing dev culture.
No new, delete operators in any C++ code.
ISR code was also in C++.
All objects are statically allocated - with 4MB of SRAM, one can easily see why. It allows tightly control memory usage by the developer.
All regression tests are automated. There were test scripts for all functional HW/SW components. Found one bug triggered in 24.9 days time frame (31 bit timer counter wrap around for 10 milliseconds timer call) - from that point on - all firmware release pass 3 months continuous test on multiple systems before release.
Agree with your point: Dev culture matter a lot. This was a mac (powerpc mac) base dev house. C++ was the big thing in the SW (Mac) side of the dev team.
In my career, I worked on 15+ projects - most were embedded system projects. Only two projects are C++. The other project only small subset is C++. On this project - 90% of code base running in target are C++ and full OO design and 80% of the classes reuse from other projects.
I don't remember. Long time ago.... Likely just steps inside makefile.
Not really a big fan of the Mac at that time - It was before Steve Jobs came back and merge the OS with Next? The Mac was very unstable. I remember it crash 3-5 times a day for my daily tasks - editing, cross compile.
It's been used in civilian avionics for a long time, too. Not that it's necessarily the best choice in those environments, but "starting to accept" seems like a mischaracterization.
I mean the embedded systems where Assembly and C89 still rule, and there is very hard to change, because the problem of adopting anything else is cultural.
Basically, while there are projects being done in C++, and many companies are finally migrating from C to C++, the large majority is sticking with C.
If you prefer to listen to someone actually relevant in the C++ embedded community, here is what Dan Saks has to say about it.
The embedded world has accepted c++ for all but the smallest microcontrollers. I was using c++ for embedded development 6 years ago and I was late to the party. All that prevented adoption be me before that was the cost of RAM.
Depends on the embedded system. I've worked on embedded systems running embedded Linux, with megabytes to gigabytes of storage, for the last dozen years, using C++.
If you're still dealing with an 8051, I'll agree that you're less likely to have moved to C++.
One other thought: Embedded toolchains are typically set at the start of the (original) project. I don't remember ever seeing a compiler upgrade happen in an existing embedded code base. And some embedded code bases live for decades.
I fully agree with you, and given my preference for type safe languages, I find interesting that other languages are also an alternative, depending on the use case constraints.
However from a few CppCon and Meeting C++ talks, it appears that in such scenarios moving beyond C, is more of a cultural issue than technology one.
Unless you consider their devices Raspberry Pi kind of platforms
Of course with companies like Microchip still focusing on Assembly and C89, C is going to stay around for a very long time
What is done in C and macros, can be safer done with C++ and constexpr templates and better optimized, problem is to change the culture of those companies.
They go with Java in very specific cases, but you need big bucks to pay for something like PTC Perc Ultra, JamaicaVM or WebSphere Real Time.
Then there is microEJ as well, but their target is that performance critical code is anyway written in C and exposed to Java.
Also depending how embedded one might consider mobile phone hardware, there is Android and Android Things.
Then there are some OEMs still selling Basic, Pascal and Oberon compilers.
But in what concerns embedded domains where only Assembly and C get used, currently C++ seems to be the only one that they care to adopt. Specially given that it already enjoys the same kind of safety regulations (MISRA, DOJ and similar).
And not everyone mind you, C++ conferences keep having sessions on how to advocate to those devs.
I've seen some people using MicroPython combined with C in embedded devices. Or plain Python on embedded Linux doohickeys. Company I work for has a few embedded Linux devices running Python.
Personally I'm hoping Rust displaces it from most of these remaining niches but even if it does it will probably happen slowly.