No. If C++ were a great language those C coders would have moved over in an instant. One of the advantages of looking at C code is that you can actually figure out in your head what the assembly will look like.
> you can actually figure out in your head what the assembly will look like
I keep hearing this, and I don't buy it. Did you know that `gcc -O3` will turn `int add(int x, int y) { return a + b; }` into an `lea` instruction? I doubt many people do.
And it's not like the compiler will magically switch to emitting different instructions if you compile the code above as C++...
Also, C++ uses a lot more memory, which can also be a no-go when you get as little as 32kb for code+data, luckily with in-place execution.
Depends on how you use it. "If you don't use it, you don't pay for it" is the C++ philosophy. If you use it as "C with objects", it should use no more memory than C with structs. If you use it as "C with polymorphism", it should use no more memory than C with function pointers.
CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”
Never cared for C beyond using it in Turbo C 2.0 for MS-DOS, and later when required to use it for university projects and client projects that explicitly required ANSI C89.
So it wasn't 64 KB, but it was perfectly usable on 640 KB systems.
The main problem has always been fighting misconceptions.
Uh. That's a pretty obvious one.
Sometimes using address generation ports is preferable to ALU ports.
Also 'lea' can load the result in a different register from both operands, 'add' will always need to modify a register.
People have been using 'lea' for calculations since dawn of time, for example:
shl ebx, 6
lea edi, [ebx*4 + ebx + 0xa0000]
add edi, eax
This was a common way in DOS days for calculating pixel address in mode 0x13.
One can do this with most C++ too. Though admittedly, non-tree virtual inheritance hierarchies, as well as member function pointers [et al] make this harder to achieve universally. I will also admit that it's easier to do with C.
If the optimizer gets its hands on either though, you may be in for a surprise no matter your choice.
In any case, C++ is copy-paste compatible with 99% of C89. So same benefits apply when using that subset.
It is plain language religion as observed at a few C++ conference talks.
The world moved from C++ to Java on the enterprise side back in the late 1990's. Why? Java was arguably faster and easier to develop in, even though many thought (including me) that C++ was technically a better language.
CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”
https://www.youtube.com/watch?v=D7Sd8A6_fYU
Embedded Development with Dan Saks
http://cppcast.com/2016/10/dan-saks/
Regarding Java vs C++, yes the enterprise world has adopted Java, however as someone doing consulting across Java, .NET and C++, I am really seeing it coming back since ANSI C++ has picked up steam again.
I see it in projects related to IoT, AI, VR, big data,....
They are all polyglot projects with C++ plus something else, not C plus something else.
As noted, unless we are speaking about PICs with 8KB and similar, the majority of them can easily be targeted by C++, which is what Arduino and ARM mbed do.
Already in MS-DOS, on 640KB computers, using C made little sense.
When we needed performance, Assembly was the only option, because the code any compiler was generating in those days was average quality on their better days.
When performance wasn't that critical, then the improved type system, RAII, reference types, type safe encapsulations were already better than using plain C.
We even had frameworks like Turbo Vision available.
So if something like a PCW 512 didn't had issues with C++, so a modern micro-controller can also be targeted by it, except for political reasons.
Developers that are against anything other than C, even if their compiler nowadays happens to be written in C++ (e.g. gcc, clang, icc, vc).
Is assembly important in microcontrollers?
Actually writing assembly is more of a last resort time.
Reading assembly is more useful, especially if your platform's debugger isn't very good.
I'm a higher level programmer. Later in my career I happen to get down to microcontrollers, what would stop me from using C++?
Your typical heap-happy usage will not go down well on a microcontroller, either. Having very constrained RAM makes heap fragmentation much more of an issue.
> Your typical heap-happy usage
Huh? 1990s C++ was typically heap-happy, which is part of the reason Java looks the way it does. Idiomatic modern C++ uses the stack as much as possible. And one can use custom allocators.
Simply put, because you can't use the STL, or a lot of other C++ features, or only with a lot of consideration.
A whole swathe of the embedded world still cares about program size in bytes. There are some that don't, but they tend to be using Linux, and are at a higher abstraction level than many others in the industry. (Industry is kinda divided in half. Those who use tiny Linux machines, and those working with microcontrollers. It's a generalization, but generally fits.)
The stuff I work on day-to-day, usually has between 1-4kb for dynamic memory, and 8-16kb for the compiled program. That line is also usually a bit blurry, and you can move things between both at runtime, but at various costs.
With C++, you get tempted to use stuff like vector, which can blow your memory stack.
I generally work with C++, but it looks like C. I get a few things like implicit pointers, for free, but generally still have to end up making most things explicit.
But, unlike twenty years ago, I no longer have to dive into assembly unless the project is pushing it's limits. The compiler tends to be "good enough".
C++, when used in that way, tends to do a lot of things behind the scenes. This is perfectly okay in a place where you have an operating system and a linker that have your back. On an embedded system none of this is guaranteed.
So, C++ can be a wonderful tool in proper hands, but it is much easier to misuse than C in an embedded context.
How initialization occurred (static or otherwise) was just something we made an explicit check off item in code review.
Additionally, most of these people are primarily electrical engineers, and don't have as strong of a background in computer science. They've been using C for decades and it does everything they want, why would they take the time to learn the boundless complexity introduced by a language that offers them (what they perceive to be) very little?
Talking to long-time C programmers about C++ is actually surprisingly difficult: https://youtu.be/D7Sd8A6_fYU