Hacker News Reader

Comment by keithnz | Hacker News Reader

Embedded Systems are quite varied these days. The one in the article sounds more at the high end of the scale. In more resource constrained environments, C is still the king. ( though I'd prefer something far more robust than C that works well on resource constrained platforms and cross compiles to ansi C ).

I think once your system is large enough, C++ is not your only option, many languages can be used.

View on HN

I've always read that there is no reason C++ cannot be used in any environment where C is used, assuming the compiler exists. There is nothing about C++ that makes it less resource-sensitive than C, and in fact with C++14 there is a tremendous amount of computation (including some instance methods!) that can be done at compile time! Scott Meyers shows some of this in his presentation at various conferences on embedded systems. It really opened my eyes to how useful templates can be in tight systems, and those don't exist in C.

To expand on this, C++ fundamentally uses the same machine model as C (or at least one that's very, very close). Where C++ differs from C is the array of high-level language constructs, which map down to that common machine model (this is what is meant by "zero-cost abstractions"). The idea is that when you use a construct like templates or virtual functions, what it compiles down to is not significantly different from the analogous code you would write in C (hand-duplicated routines with different concrete types and structs-of-function-pointers, resp.).

There are exceptions (no pun intended) to this, namely exceptions, RTTI, global construction/destruction, and the intricacies of new/delete. As the article points out (as will anyone who advocates the use of C++ in constrained environments), none of these are really necessary to use C++ effectively and can be safely stubbed out.

Agree. There is a lot to be gained from using C++ with absolutely no or imperceptible overhead.

I guess the only common embedded systems I would think twice before using C++ nowadays is 8051 and the very low end AVR/PIC (which can have as little as 32 bytes of RAM).

Yep, Turbo C++ for MS-DOS was perfectly happy with 512 - 640 KB.

> Agree. There is a lot to be gained from using C++ with absolutely no or imperceptible overhead.

i would agree only if there is sufficient discipline and experience on the team, management included. Spaghetti C++ can be a lot harder to untangle than spaghetti C, in my experience.

But cpp is much safer than C and a lot of common bugs in C don't exist in modern cpp.

Agreed. It's worth noting that Arduinos, by default, are programmed in C++ (thanks the AVR port of GCC), and it's been this way more or less since their first version, which (as far as I recall) was a fairly small 8-bit micro. There's plenty of even less powerful micros, but it seems like architecture and tooling are really more of a constraint than capacity (e.g. low-end PIC micros have a less C-friendly architecture).

Absolutely. There was a fantastic talk at CppCon last year, using C++17 to program a game for the Commodore 64. Using standard C++ idioms, the optimizer was easily able to make it compile down to efficient machine code.

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

I started using C++ back in MS-DOS 5 days, meaning between 512 and 640 KB of RAM.

Many modern micro-controllers have at least this amount of RAM.

Regarding C vs C++, it has been a constant fight since those days.

Except that C++ is like 4 totally different languages over the years.

So, which one should I write in? And this company hates exceptions while that company doesn't allow dynamic allocations so I've got different dialects even IF you can get everybody to agree on which dialect of C++ you should write in.

And, why should I learn C++14 when C++17/18/19 will be another different language?

No, I'd rather put in the effort to make Rust usable. The C++ ship has sailed.

I'm incredibly interested in getting Rust into embedded devices, but it's a much larger sell than moving from C to C++14. And how will C++17 onward be so much different? C++11 was a huge inflection point, no doubt, but the standards committee works tirelessly to make things backwards-compatible.

> And, why should I learn C++14 when C++17/18/19 will be another different language?

While it is indeed a pain to look at source code and understand the differences, the C++ standard gets very few releases than say Python or Ruby, and I doubt anyone can list all the differences between language versions without searching for them.

> No, I'd rather put in the effort to make Rust usable. The C++ ship has sailed.

Me too, but when it comes to what customers allow me to use, it is C++.

Sony and BMW are just now migrating to C++11 (not C++14, C++17, ...), how many years do you think it will take for something else to reach similar scale?

Which is why I am supportive of all attempts to improve the overall quality of C++, even C (UNIX variants are not going away) for that matter.

Rust still needs to improve a few things, which are anyway part of the 2017 roadmap, before Sony, BMW, Apple, Microsoft, IBM and similar companies decide to go Rust instead of C++yz or Swift.

It is a large language but, for me, I just think it's an awesome toolset to work with. Is not for everyone.

Also you are shouting a bit hyperbole. Each new standard does not erase the prior standard. C++17 does not remove the features from ++14. Each new version focuses on different things, and they have been really great additions.

Also there is no C++18 or 19.

> Also you are shouting a bit hyperbole. Each new standard does not erase the prior standard. C++17 does not remove the features from ++14. Each new version focuses on different things, and they have been really great additions.

I am not shouting hyperbole at all. Each new standard completely changes the way you are supposed to write new C++ code. The problem is that the legacy code was written the old way, with all the problems that entails.

So, you have to know everything about the new way AND you have to know all the pitfalls of the old ways for when you need to go debugging through the old code. Um, no thanks.

I've been following C++ since 1996-ish. I stopped following it after 2011. It's just not worth the pain.

As the article and others here have said, if you have the requisite proficiency and understanding of C++ and the C++ compiler(s) that you're using, and if you are using a high quality optimizing compiler like GCC, there is no reason that C++ code will be any larger in footprint than C code.

As the author points out, C++ offers very significant and tangible benefits, and in the right hands/with the right discipline should be less error prone and result in more efficient code. In my opinion, C++'s greatest benefit for embedded programming is that it has a wealth of abstractions that have no runtime overhead.

The are several reasons that C is still king, but I suspect the main one is portability. Your company may need to be able to port its software to some obscure microcontroller where the only compiler available is a buggy C89 implementation. Or if it has C++ support, odds are that it is inefficient and out of date.

Because of this and other reasons, the labor pool of "deeply" embedded software engineers has a heavy bias towards C over C++. This compounds the problem, reducing the incentive for embedded engineers to learn modern C++.

You are forgetting the ones that "only over my dead body" kind of folks.

Which according to Dan Saks talk at CppCon and interview at CppCast, there are plenty of them in the embedded space.

SPARK is defacto, safe language for embedded. Smallest I heard it used on was 8-bit AVR:

https://en.m.wikipedia.org/wiki/SPARK_(programming_language)

Ivory might git your requirements:

http://ivorylang.org/ivory-introduction.html

Tower is their other one:

https://github.com/GaloisInc/tower/blob/master/README.md

ATS is used here on an 8-bitter:

https://github.com/fpiot/arduino-ats/blob/master/README.md

I don't think we read the same article; "higher end of the scale" is not going to be bothered by RTTI and exceptions which TFA suggests disabling. Overhead of C++ without those vs C is pretty minimal.

Reply on news.ycombinator.com