[pjmlp]

I gateway drug to C++, was Turbo C++ 1.0 for MS-DOS, released in 1990 as per Wikipedia. I got my copy in 1992.

Basically C++ARM as per language standard, on a 386SX running at 20 MHz, 2 MB but 640 KB was more than enough, right? :)

Our high school teacher giving us C classes with Turbo C 2.0 also had it around, so as it were back in those days, I eventually got a copy.

My gateway drug to programming until then were Turbo Pascal 6.0 and TASM, and C++ was in the same ballpark of features and culture for safer systems programming.

Never had any issues using it in such kind of PCs, including with my own bounds checked string and array classes, hardware that most modern MCUs can easily outperform.

[rleigh]

Absolutely. Modern MCUs are phenomenal. More powerful than mid '90s top-end PCs. Add some external SDRAM and storage, and they have more and faster memory and storage as well. C++ is perfectly good. Better than all the nasty C macros in the vendor HALs, if you replace that nastiness with some type-safe enums and inline functions. There's plenty of capacity for running Python or Lua as embedded scripting languages even on smaller variants, both of which wrap C++ nicely. I'm fairly new to the embedded world, but so far it's been mostly a pleasure to write code for a variety of TI, ST and Nordic MCUs; some with C, some with C++.

I do see why people like C for embedded use; when it comes to hardware interaction you have complete visibility into all of the interactions with special registers. Looking through the disassembly when debugging is nice and straightforward. But C++ does this and more, so long as you don't go overboard with unnecessary complexity. It's fine with a bit of self-discipline, and all that extra bounds checking and such is of value.

[pjmlp]

In case you never seen this, enjoy Jason Turner's “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17” talk. :)

https://www.youtube.com/watch?v=zBkNBP00wJE