[bb88]

> C is king because the industry is currently dominated by people who have been doing this since before C++ was a thing.

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.

[atilaneves]

They'd move over if technical considerations were the only reason why people choose programming languages. In my experience it tends to be psychological ones.

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

[koffiezet]

Psychological ones? No, simply the lack of available reliable compilers for some platforms was my problem. I developed POS applications, where C++ would have worked fine, if we had a decent C++ compiler on every platform we wanted to support. Some platforms used GCC, but most used proprietary compilers - where C++ support was completely absent or very scetchy. When you can't use exceptions, the memory allocator is absolute garbage and leaks stuff on it's own and encounter various random compiler bugs, you quickly decide to stick with plain old C. C++ in my experience was an absolute mess when it came to embedded work (note that the last embedded work I did dates back from 2006, so not sure what the current situation is)

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.

[AnimalMuppet]

> Also, C++ uses a lot more memory...

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.

[pjmlp]

Modern C++ does just fine on a Commodore C64.

CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”

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

[bb88]

Sad that it took C++ almost 40 years to get there.

[pjmlp]

I was doing C++ development on MS-DOS already in the 90's.

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.

[vardump]

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

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

== y * 320 + x + framebuffer address.

This was a common way in DOS days for calculating pixel address in mode 0x13.

[ShroudedNight]

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

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.

[vardump]

C++ extra object copies can sometimes be pretty difficult to see without checking disassembler listing.

[pjmlp]

Only when compiling without any kind of optimizations, nor using vector instructions.

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.

[bb88]

I think you're not giving engineers enough credit here.

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.

[pjmlp]

So, I will let one of the renowned experts speak instead.

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.

[freeone3000]

It is very hard to get a Java or Python programmer (what those AI guys want to use) to move to C, even if they HAVE to use something native. So C++ is where they end up.

[pjmlp]

This whole thread started about embedded development.

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

[pknopf]

Ah, I forgot about the assembly.

Is assembly important in microcontrollers?

[viraptor]

Sometimes. Usually you just write "normal" C, until you realise your single `sprintf` use took 20% of your ROM size. Or until you need some interrupt handler to take no more than N cycles. You probably don't switch to assembly at that point, but you definitely start checking what the compiler output is and where are the bytes/cycles wasted.

Actually writing assembly is more of a last resort time.

[tluyben2]

Because of cost we use very constrained microcontrollers; every byte literally counts. In the end it really matters cost wise (in mass production embedded every cent counts as well; using a high spec mcu just costs more) but we had to rewrite from C to assembly to get a few more kb for features in the flash. C++ or Rust are generally not good for the cost of materials.

[pjc50]

Writing assembly tends to be restricted to the bits where you need it - special function prologues for interrupt handlers, requiring a particular unusual instruction for something, time-sensitive or cycle-accurate "beam racing" code.

Reading assembly is more useful, especially if your platform's debugger isn't very good.

[torn_pages]

I would say it does. I learned microcontroller programming in assembly before I learned about C.