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

Additionally, most of these people are primarily electrical engineers, and don't have as strong of a background in computer science. They've been using C for decades and it does everything they want, why would they take the time to learn the boundless complexity introduced by a language that offers them (what they perceive to be) very little?

Talking to long-time C programmers about C++ is actually surprisingly difficult: https://youtu.be/D7Sd8A6_fYU

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

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

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.

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

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

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

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.

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

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

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

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.

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.

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.

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.

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

Ah, I forgot about the assembly.

Is assembly important in microcontrollers?

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.

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.

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.

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

Let me ask it this way:

I'm a higher level programmer. Later in my career I happen to get down to microcontrollers, what would stop me from using C++?

The standard library (with all its' duplicate code resulting from hardcore templating) will blow up your flash space usage significantly, to the point where you will run out of it sooner than you expect. You will spend time finding alternative standard libraries that are size-optimized and you might end up rewriting a lot of what you take for granted in your C++ daily usage. For example, the Arduino environment is C++-based, but it's not anything like on the desktop due to it not shipping an std:: .

Your typical heap-happy usage will not go down well on a microcontroller, either. Having very constrained RAM makes heap fragmentation much more of an issue.

Then don't use the standard library. Don't even link it in.

> Your typical heap-happy usage

Huh? 1990s C++ was typically heap-happy, which is part of the reason Java looks the way it does. Idiomatic modern C++ uses the stack as much as possible. And one can use custom allocators.

Not a good fit for systems with small hardware stacks - PIC16 is still in use http://www.microcontrollerboard.com/pic_memory_organization....

A lot of people do. But they may as well not. They tend to write C-style C++.

Simply put, because you can't use the STL, or a lot of other C++ features, or only with a lot of consideration.

A whole swathe of the embedded world still cares about program size in bytes. There are some that don't, but they tend to be using Linux, and are at a higher abstraction level than many others in the industry. (Industry is kinda divided in half. Those who use tiny Linux machines, and those working with microcontrollers. It's a generalization, but generally fits.)

The stuff I work on day-to-day, usually has between 1-4kb for dynamic memory, and 8-16kb for the compiled program. That line is also usually a bit blurry, and you can move things between both at runtime, but at various costs.

With C++, you get tempted to use stuff like vector, which can blow your memory stack.

I generally work with C++, but it looks like C. I get a few things like implicit pointers, for free, but generally still have to end up making most things explicit.

But, unlike twenty years ago, I no longer have to dive into assembly unless the project is pushing it's limits. The compiler tends to be "good enough".

It really depends how you use it. If you are approaching from the standpoint of "I am writing code on a microcontroller", which means no exceptions, no static initializers, probably no templates, definitely no rtti, then it will be all okay. If you approach it from the standpoint of "I'm just programming, how hard could it be? Let's just use std::", you're going to have a very bad time and very quickly.

C++, when used in that way, tends to do a lot of things behind the scenes. This is perfectly okay in a place where you have an operating system and a linker that have your back. On an embedded system none of this is guaranteed.

Static initializers and templates are great in a deeply embedded context, IMO.

For you yes, since you know how they are implemented at linker level. But get a few junior devs on your team, and you'll be wondering why hundreds of thousands of cycles run before main is called, or why some driver code is being entered before it is initialized, since someone decided to make a static singleton object for some driver and called some driver method in the constructor which will run before main(), not realizing how this stuff really works underneath.

So, C++ can be a wonderful tool in proper hands, but it is much easier to misuse than C in an embedded context.

If you let junior programmers fuck up your codebase that much, that's not the junior's fault. You should do code reviews.

I lead a team of six, including some junior devs.

How initialization occurred (static or otherwise) was just something we made an explicit check off item in code review.

Awesome. Glad it worked out for you. I hope it stays so after you leave the team or no longer have time for each code review.

Constexpr init can also be great in that case To initialize rom with complex objects.

note, static initializers works in embedded you need to execute functions between __init_array_start and __init_array_end before using any static object in gcc somewhere in program

I'm well aware of that. But giant array of static Constructors makes it hard to reason about when any piece of Hardware is accessed since a lot of stuff happens before Main (). Especially for people who don't play with the insides of linkers for fun on weekends.

Sorry that sounded like i'm scorching you i didn't mean it. Yes agree with when using HW initializing code in constructors I ended with two types of 'constructors/inits': 1 - for object initialization 2 - just for hardware and calling manually :/.

Nothing. I've worked on Cortex-M4 projects in C++. It's nice in many ways. The people working on the project had a much more diverse background than the typical EE who learned C as an undergrad mentioned in another thread.

Not much. The Arduino programming environment is really gcc in C++ mode, but a different library.

It's more difficult. I used C++ in many projects for years and enjoyed working with it. You have to be very disciplined, though, and you need to know a lot about how it works under the hood to get it to play nicely, but it has it's niche. Embedded is not it's niche IMHO (and I've also done embedded, where we specifically chose to use C over C++).

Really, whenever you are doing any kind of embedded or real time project you are basically doing "resource limited development". The resource can be memory, I/O, CPU or any and all of that (or more). You need to be able to control exactly how it's used. C++ is often used to abstract you away from those things -- which is exactly the opposite of what you want.

C is a high-ish level language that is close enough to the metal that you can fairly easily understand the implications of what you are doing. C++ is not and it's incredibly easy to build a monstrocity that chews memory -- not just working memory, but application size too. Even dealing with name mangling is a surprising PITA when you are dealing with embedded -- remember embedded means you often have to build your own tools because nobody else is using your platform ;-).

Like I said, I actually like C++ (or at least C++ of a couple of decades ago -- the language seems to have changed a lot since I last used it, so it's hard for me to say). There are a lot of times where I simply don't care about controlling resources to that level. These days there are a lot of other choices and I'm not sure that I would ever choose C++ for a project again, but definitely back in the day it was something I reached for quite a bit.

WRT Rust, I agree with the OP that the borrow checker is really nice. I recently spent some time playing with Rust to see how easy it was to implement higher level abstractions. One of the things I was really impressed with was how hard Rust slaps you when you try to do something that would explode your memory footprint. It still feels a bit immature to me, but it has tremendous promise (and if you don't mind working around the immaturity, it's probably fine to use at the moment).

About 15 years ago I did some PIC16 programming immediately after a lot of C++, so I tried working in a C++ style.

The first obstacle was that there was no C++ compiler.

So I wrote some very C++ style C: nice little structs with associated functions for mainpulating them, which took a pointer to struct as first argument.

The code did not fit in the PIC.

It turns out that the PIC16 lacks certain indirect addressing modes, so every access to a structure member from a pointer turns into a long sequence of instructions to do the arithmetic.

Oh, and this particular chip only allows you a maximum stack depth of 8, so you have to ration your use of utility functions. The compiler is bad at inlining so macros are prefereable.

By the time I had finished it was an extremely C program with no trace of C++ style at all.

The situation has got a lot better but there are still limitations which will trip up the unwary. And one day someone's going to point out that they can save $0.50 on every one of a million devices if you use one of these tiny chips with no indirect addressing and limited stack.

I find it easier to use C and assembly on very constrained devices becauee I know what the output will be; with C++ it is less clear. If you write code that has to fit in 24kb, you need to think about what every instruction looks like after compilation and that just is far easier with C and (obviously) asm in my experience.

I’m not an embedded developer, but my guess is that if they’re not even using dynamic memory, I doubt they need or want anything that C++ has to offer.

That's more a matter of experience and attitude -- even simple things like reference types are nice. Also, templates offer a lot of abstraction power that can be used to model the hardware nicely, without sacrificing efficiency.

Many embedded programmers come from a background that doesn't expose them to those sorts of ideas though.

Can confirm, C++ has some nice features which I'd even like without malloc. OTOH I'm already horrified at the code quality problems pretty much every embedded shop faces. C++ would only make this matter worse.

As a software inclined embedded guy I also often think of what would be possible if we switched to C++. But then I think of what's probable.

Even without dynamic memory there's ton of useful things:

Namespaces, References, collection types (std::array, string_view, intrusive containers, etc.), RAII (release mutexes at scope ends), strong typing, proper encapsulation, interfaces, etc.

In general tools for constraining hardware complexity like namespaces and encapsulation are a lot less important for the project sizes where you're typically working with embedded systems. For the rest they mostly provide some benefit but that's offset by the danger of a move to a much, much larger and more complicated language in an environment where many people writing code are primarily EEs and most C++ answers they Google will provide solutions inappropriate for embedded development. And I say this as someone who was one of those EEs when he started out.

RAII is absolutely killer. Managing real time priorities with lock_guards so that you can never forget to drop priority will win over almost any grizzly old firmware engineer.

There is still a lot to be gained by strong typing even in projects where everything is statically allocated.

Many people need in memory databases and linked lists (or binary trees) to hash information and sort it.

There's a case to be made for an OO style program where I create an object and give it a chunk of memory to manage a B-tree, so I can keep my memory from being fragmented, but using C++ for that is serious overkill.

I can see people arguing for object oriented over procedural.

As I type that, I realize I've recently learned to love Go, so maybe it is my bias.

A lot of it is due to the fact that many of these chips use ancient compilers, so the C++ support isn't that good.

I don't know why. But it's true.

Here's a rant by Linus Torvalds. Take the politics and snark with a grain of salt. His technical arguments, however, are spot on.

http://harmful.cat-v.org/software/c++/linus

I'm not sure how much water his argument here holds anymore. C++ has changed A LOT since 2007; idiomatic C++11 is an extremely different language from C++03, and C++20 is almost unrecognizable to an early C++ developer.

I bet you $5 if you ask him, he'd probably say the exact same thing.

He writes C++ now, so I imagine he'd say the language has its place. https://en.wikipedia.org/wiki/Subsurface_(software) (He'd probably still say C++ is inappropriate for the Linux kernel, though.)

I was going to honor my bet here, until I did a little googling and found this during the discussion of when they ported subsurface to Qt.

"A word of warning: Linus has very strong feelings about all the things that are wrong with C++ and at times has been known to be less diplomatic than me when explaining his point of view... :-) But he made a clear statement that he is interested in seeing this port happening, as long as most of the program logic that is not UI code stays in (quote) "sane C files". So please keep that in mind as we drive this further."

http://lists.subsurface-divelog.org/pipermail/subsurface/201...