Makes some really great points, similar to why C++ is not favored for embedded. C++ compilers are just too unpredictable and when trying to meet code limits in 128K, 32K or even 2K of flash, C++ is a nightmare. All of the major embedded SDKs (STM, Microchip, SiLabs, TI, NXP, I could go on) are written in C... and C only. MBED is C++, but I've never encountered or heard of an OEM or integrator using MBED in a real product.
I use Keil, IAR, Renesas's compiler, XM8/16/32 from Microchip, and GCC.
Which do you use?
One of the main features of C++, its object-oriented stuff, is built on top of constructors and destructors -- aka dynamic memory allocation. This sort of thing is not desirable on deeply embedded systems due to resource constraints and the very real spectre of heap fragmentation -- embedded stuff tends to rely on static memory allocation done at compile time or system startup.
C++ isn't quite as portable as C -- Not just the compilers which never quite supported the same combinations of features -- even if you just stuck with the ISO-ratified features -- but the language runtime, standard [template] library, and headers are far larger with various implementations including plenty of mis-features and quirks. All of this meant that it was quite common for C++ code to not even compile with a different toolchain -- especially when templates were used -- and even if it did compile, it might not actually function correctly.
If you restricted yourself to avoid the problematic areas of C++ (eg not using templates or dynamic allocations) you'll end up with a language that is basically C. So why not just use C? :)
As you said, there are no vendor SDKs out there (that I know of, anyways) that are C++. But it's not terribly hard to integrate them in to a C++ codebase / roll your own abstractions because you're dissatisfied with the ones the vendor gives you (;
Different compilers supporting different subsets of the standard is definitely an issue, and it can be a problem if you're trying to use the same code with several different toolchains.
GCC in particular however has been really good about keeping up with newer versions of the C++ standard. I like and use many of the things on this list (excepting the standard library features, which of course you usually can't use off the shelf because dynamic memory allocation): https://github.com/AnthonyCalandra/modern-cpp-features.
In particular, features such as constexpr lambda, if constexpr, and type traits are nice ways to do some compile-time computation while being type safe - they're a lot more pleasant to work with than C preprocessor macros.
And of course, templates. They're a nice way to express certain concepts and reduce duplication without making any impact on your code size. But only judiciously, otherwise you will wreck your compile times (;
> Makes some really great points, similar to why C++ is not favored for embedded. C++ compilers are just too unpredictable and when trying to meet code limits in 128K, 32K or even 2K of flash, C++ is a nightmare. All of the major embedded SDKs (STM, Microchip, SiLabs, TI, NXP, I could go on) are written in C... and C only.
OTOH Arduino is C++ and works fine for millions of people, I've also dabbled a bit in various AVR, STM32 and ESP8266, all in C++.
Arduino is a sandbox for people with little experience in embedded programming to dip a toe. They aren't interested in writing optimized constrained code, which is what 99% of embedded programming for products is about. Two totally different spheres.