Yeah, safety and IoT unfortunately aren't something that go together.
Using C++ doesn't require OOP all over the place, nor crazy template metaprogramming.
The same reason you give for using macros.
C++ is used mostly with exceptions disabled on embedded, so failing constructors are a PITA. You have to keep track of valid states with a bool. Now every function entry has:
if (!m_bValid)
return;
> Yeah, safety and IoT unfortunately aren't something that go together.
Don't forget that IoT is just a minuscule fraction of embedded. Not everything is connected online or requires safety as top priority.
> Using C++ doesn't require OOP all over the place, nor crazy template metaprogramming.
So we agree. But I think you should be considering the possibility that there might be something going on between you and C, and that it could be possible that not every C developer out there is out of their mind (considering the quantity of past, present and future C projects).
Make peace with C, because the world runs on C and we'll be long gone by the time C will be replaced by something else :)
The "exceptions are evil, but without exceptions you can't fail a constructor!" is a really irritating canard when it comes to C++. First off all, the terribleness of exceptions is way overhyped, but even if you do want to avoid them, this is not a problem: just use a factory function instead of a constructor and return a `std::optional` (or a default-constructed value and an error code if you want to avoid `std::optional` for some weird reason).
I like pure C a lot and it definitely has a place in areas like embedded. But this kind reflexive disdain for C++ using uninformed arguments is really tiresome. C++ is fine.
It's not that exceptions are terrible. I have nothing against them. The thing is that most of the time they are not affordable, especially in embedded. Some compilers don't even support them (some 8-bit IIRC). Most (including mine) embedded C++ programs have exceptions disabled.
> return a `std::optional`
The same goes for std. I don't know the overhead of possibly duplicating these classes(1) for every instance of std::optional. Most (including mine) embedded C++ programs don't use std.
30KB of extra code is nothing for desktop/server applications, but it's not convenient for a MCU with 64KB of flash.
(1): https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-...
> just use a factory function instead
This is practical with an efficient heap allocator (which I might not have). What happens if I want a scoped (on stack) instance of a class?
See how things are quickly getting more complicated with C++?
When I got introduced to C++, via Turbo C++ 1.0 for MS-DOS in 1993, I decided that there was hardly a reason to use C other than being forced to use it by external reasons.
Thankfully there are plenty of places that have moved beyond running on C. :)
Can we agree that for at least the past 25 years, 99% of devices runs on C and/or depends on C and/or relies on C, or its development ran/relied/depended on C? From Windows/MacOS/Linux kernels up to the FW in your mouse, keyboard, monitor and HDD controllers.
It's difficult to escape C :)