Hacker News Reader

Comment by hellofunk | Hacker News Reader

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.

View on HN

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.

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

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

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.

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.

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.

Reply on news.ycombinator.com