[pjmlp]

The same subsets are available in C++ as well, with stronger type checking and RAII for closing those handles.

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.

[scoutt]

> RAII

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;

I hate it.

> 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 :)

[OskarS]

Yeah, checking return codes is a thing you NEVER have to do in C...

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.

[scoutt]

> the terribleness of exceptions is way overhyped

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++?

[OskarS]

It's that amount of lines UNCOMPILED. Of course uncompiled code wouldn't fit in 64kb of flash (the compiler wouldn't fit either, you know). Compiled, std::optional takes up essentially no overhead, basically the same as if you're returning a single bool along with your object.

> 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?

There is absolutely no reason to do a heap allocation for a factory function in modern C++ (or even relatively ancient C++, in fact). The fact that you would think so indicates you simply don't know C++ at all.

Tell me, where in these six lines do you see a heap allocation? Where in the total of 6 instructions this compiles down to do you see anything that couldn't run in any embedded environment? Tell me how these six instructions wouldn't fit inside your 64kb of flash:

https://godbolt.org/z/rErWPbbbx

And again, EVEN IF you're so religiously and irrationally opposed to using std::optional, you can just return a default-constructed object and an extra bool indicating successful construction. I don't know why you would considering you could just return an optional, but whatever, you can do it that way if that's what you prefer.

You're just wrong about this stuff, and it's this kind of lazy, uniformed criticism of C++ that really rubs me the wrong way. If you wanna use C, use C! Nobody's stopping you, it's a fine language. Just leave the C++ discussions to the people who actually know what the language is.

[scoutt]

Just chill, OskarS. I know the difference between compiled code and source code. Regarding std::optional, I even admitted "I don't know the overhead of possibly duplicating...".

30KB was a ballpark about exceptions plus std in general, by including things you expect to use when using std (like std::string).

The patterns I knew and saw with std::optional usually returned "new something", but yeah, you can return a copy too if the class fits in the stack.

And I am not religiously and irrationally opposed to anything.

> really rubs me the wrong way

Relax, my friend. Life is short.

[OskarS]

> The patterns I knew and saw with std::optional usually returned "new something", but yeah, you can return a copy too if the class fits in the stack.

Oh, fer crying out loud... It DOES NOT return a copy, it constructs it directly in place. This is called "copy elision" (also known as "return value optimization", or RVO), and has been done by compilers for three decades, and is actually mandated behaviour in modern C++. I don't know where you saw these examples, but you would never use operator new with std::optional: it takes a value, not a pointer.

You have a very annoying style of being wrong about absolutely everything you say, and then acting superior about it when people call you on your bullshit.

[pjmlp]

In the history of C++, RAII predates exceptions by several years.

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. :)

[scoutt]

> 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 :)

[pjmlp]

Using C compilers written in C++, yeah really difficult to escape C.

Windows has been migrating into C++ since Windows Vista, when VC++ introduced kernel support. Its C universal runtime is written in C++ with extern "C" entry points. Ah and then there is COM/WinRT, also mostly about C++ and .NET, even if the ABI is compatible with C (for masochists).

macOS uses C++ for drivers, a kernel without drivers isn't of much use.

Speaking of which, in Android all drivers written using Project Treble (required as of Android 8) are either C++ or Java based, and now Rust is also into the picture. The only C is the "classical" Linux upstream stuff.