Have the Embedded world gone ape? 10 years time?

[MT]

The basic idea is that people overwhelmingly prefer taking on risk in situations where they know specific odds rather than an alternative risk scenario in which the odds are completely ambiguous—they will always choose a known probability of winning over an unknown probability of winning even if the known probability is low and the unknown probability could be a guarantee of winning. That is, given a choice of risks to take (such as bets), people "prefer the devil they know" rather than assuming a risk where odds are difficult or impossible to calculate as in C v.s C++. 

[c4757p]

It's not a "risk" though. Don't be afraid of the assembly. Look at it and see how much of your resources something used. If too much, use something else. If you're afraid of assembly dumps you're not an embedded developer.

[MT]

C v.s C++!.... I fondly recall my Z80 assembler years in spring 1824 just prior the French revolution!
People are afraid of C++1314!

[legacy]

I wish I had the time and the resources (and the skills) to develop a "safeC" C compiler, based on C99, but MISRA by design.
but, more afraid about C++, which is more complex to be designed (and to understand, when you have to use)

p.s.
why C++ ? I needed to work with fixed point, C has no support, but C++ can overload, so I designed a custom library to have a native support for fixed point.
(fpga softcore, programmed with C++)

[legacy]

here we discussed about concurrency, I think it will be THE trouble with the C language as soon as we will have a lot of cores in our MPU devices 

[richardman]

re: fixed point
Embedded C, which is not a Standard, but an ... "advisory"? Anyway, it adds fixed point data point, so no need to roll your own.

We will be adding that in Q1 2016.

[janoc]

What the hell kind of argument is that? I don't use malloc and free on a microcontroller either, typically don't use floating-point, etc... We're talking about a language, not a shovelful of every excessively complicated thing in its standard library just thrown in because we like them. One always has to tread carefully when doing embedded development, that says nothing about the language.

As far as I know things like exceptions, new/delete, RTTI are parts of the language standard, not some optional extra or ("a shovelful of every excessively complicated thing" as you call them). So you are basically using only a tiny subset of the language (nothing wrong with that, btw) but making generalized statements about it.

[c4757p]

My "generalized statements" are correct. You are trying to claim that even if you don't use the heavier features of C++, they will pull in code to support them 'just in case'. I demonstrated that to be false. If you want to claim that C++ is poorly suited for embedded development because some of its optional features are, fine, that's an opinion and I'm not the least bit interested in discussing people's programming opinions. But saying that features you don't use increase code size is an attempt at stating fact, and statements of fact can be tested.

[tggzzz]

I demonstrated that to be false.

To be a little more precise, you demonstrated that in one example for one architecture using one version of one compiler and one set of compiler flags where the compiler complies (to some extent) with one version of a language standard.

C/C++ is notorious for having too many variations for all of the above.

[c4757p]

Well, let's get some more tests in here, shall we? I did AVR because I'm familiar enough with it to dig into the assembly dumps. Anyone here for ARM?

Obviously - as I said - there are crap compilers. I wouldn't expect Microchip's excuses for compilers to perform particularly well here, for instance, if they even support C++

If you're stuck with a poor compiler, obviously you're going to be limited.

[tggzzz]

Well, let's get some more tests in here, shall we? I did AVR because I'm familiar enough with it to dig into the assembly dumps. Anyone here for ARM?

Changing the statement to "To be a little more precise, you demonstrated that in one example for two architectures using one version of one compiler and one set of compiler flags where the compiler complies (to some extent) with one version of a language standard" is not much better. Especially when there are so many varieties of ARM.

Obviously - as I said - there are crap compilers. I wouldn't expect Microchip's excuses for compilers to perform particularly well here, for instance, if they even support C++

If you're stuck with a poor compiler, obviously you're going to be limited.

All C/C++ compilers are crap in some respects. For example, even in 2015 gcc doesn't support C++11 (it supports bits of it). Are there any full C++11 compilers yet?

[c4757p]

Well, let's get some more tests in here, shall we? I did AVR because I'm familiar enough with it to dig into the assembly dumps. Anyone here for ARM?

Changing the statement to "To be a little more precise, you demonstrated that in one example for two architectures using one version of one compiler and one set of compiler flags where the compiler complies (to some extent) with one version of a language standard" is not much better. Especially when there are so many varieties of ARM.

It's infinitely better when it's a statement about the architecture and compiler you want to use. Or do you seriously refuse to use anything because some obscure platform somewhere in the world doesn't support it?

Obviously - as I said - there are crap compilers. I wouldn't expect Microchip's excuses for compilers to perform particularly well here, for instance, if they even support C++

If you're stuck with a poor compiler, obviously you're going to be limited.

All C/C++ compilers are crap in some respects. For example, even in 2015 gcc doesn't support C++11 (it supports bits of it). Are there any full C++11 compilers yet?

Fine, "crap" was an opinionated statement. I figured a tautological "obviously, compilers that don't support feature X don't support feature X" would be too patronizing - but it's the truth. Generic claims that a language is poor for embedded because not every single platform implements it properly aren't useful.

janoc said:

Unless you really need the OOP machinery with classes, inheritance, templates and what not you are only imposing a significant compilation time and code size overhead (the C++ runtime) on yourself with few to none benefits over straight C.

I never attempted to claim every feature of the latest version of C++ was suitable for use on every platform with every compiler. I merely claimed, and showed for one example, that the runtime overhead doesn't exist. Perhaps you can find a platform for which it does, in which case you probably shouldn't use it there. But on many, it doesn't. As a general statement that it is a necessary consequence of using C++, it's utterly false. No good as general advice. Where it's true, it's a flaw of your specific chosen platform and toolchain.

You'll find development a lot more enjoyable if you stop avoiding things because something somewhere doesn't support them. C++ has rather a lot of nice stuff you could use. Come to the dark side, we have cookies.  O0

[miguelvp]

GCC 5.0 and Clang 3.4 have full C++11 and C++14 support
Intel's and Microsoft's compilers fully support C++11 as well.

Source:
http://en.cppreference.com/w/cpp/compiler_support

[andersm]

Changing the statement to "To be a little more precise, you demonstrated that in one example for two architectures using one version of one compiler and one set of compiler flags where the compiler complies (to some extent) with one version of a language standard" is not much better. Especially when there are so many varieties of ARM.

If you keep moving the goalposts, I'm sure you'll eventually find something that backs your points, but at some point it'll just start looking contrived.

There must be something very special about embedded systems, because no matter how fast they get or how much memory they have, they're still somehow always too small and too slow for C++. At some point it was inconceivable to program embedded systems in something as wasteful as C, but somehow we as a species survived that ordeal as well.

For example, even in 2015 gcc doesn't support C++11 (it supports bits of it). Are there any full C++11 compilers yet?

GCC supports everything except garbage collection, libstdc++ has a few items that are missing or only partially implemented. Clang has couple of unimplemented features (GC, C99 extended integral types), but libc++ claims complete support for both C++11 and C++14.

[c4757p]

GCC supports everything except garbage collection

Embedded garbage collection, I believe, is where you set a bin out for everybody to throw away their microcontrollers that don't support C++. This should be easily supported by GCC.

[richardman]

...
There must be something very special about embedded systems, because no matter how fast they get or how much memory they have, they're still somehow always too small and too slow for C++. ...

Do you work in the industry? If you do,  you would know why.

As I said a few times already: embedded system programmers generally are not software engineers. This is the reality. It does not matter how many better Go/Swift/C++/MicroPython etc. are. They will not get traction until that fact changes.

[c4757p]

embedded system programmers generally are not software engineers.

How sad, that they're writing software for a living and won't deign to learn software engineering. It feels like the embedded world just wants to live a perpetual amateur hour. Reminds me of the old electrical engineers who won't admit that it's 2015 and they should probably learn to code.

[Marco]

Ehh, once you start using C++ as C with slightly more syntactic sugar around struct based classes and with easier to use comments I doubt it speeds up development much.

PS. the entire IT industry is amateur hour, can I have some more buffer overflows?

[c4757p]

Well, it's fine if you don't like it or don't think it's very useful for you - as long as you don't start giving bullshit reasons why it's broken. You can say you don't think you need its features without saying they'll magically bloat your code by just being there.

PS. the entire IT industry is amateur hour, can I have some more buffer overflows?

Yeah, gimme a minute, I'm sure I can find one for you...

[westfw]

I found this interesting discussion pursuing another forum's comments:  http://programmers.stackexchange.com/questions/48401/learning-c-properly-not-c-with-classes
Which I basically interpret as "if you're not using the bloated parts of C++, you're not doing it right."  :-(
Their "good example" is about 60% bigger than their "bad example" (compiled for x86 MacOS.)

And yet people wonder why embedded engineers are scared away...

[Kalvin]

Complex numbers are part of the C++ (std::complex). Those who have been awake on the math classes know that the real numbers are the subset of the complex numbers.
 
So, does that imply that if I am using just the double or float numbers (subset of the complex numbers) and not using std::complex, that I am not really programming in C++?

More precisely, if I use only the specific subset of the C++ and not using the std::-libraries, multiple inheritance, RTTI, exceptions or any place-your-favourite-C++-feature-here because of the code bloat, or the specific feature is considered unusable for the small embedded MCUs, does it imply that I am not really programming in C++?

It seems that some of the arguments suggest that one should always use the full language features in order to justify its usage. Here is then a hint for those so called "programmers": Next time you use doule or float, please use std::complex instead, and perform your computations using only the complex numbers, because you do not want to use only the subset of the numeric space the C++ is providing.

[nctnico]

Well, it's fine if you don't like it or don't think it's very useful for you - as long as you don't start giving bullshit reasons why it's broken.

I agree. C++ offers many features to make programming quicker and with some care you can avoid using pointers because you can pass variables by reference. I often see obfustigated constructs where people use function pointers in C to make objects. It works but at that point it is time to switch to C++ and use classes.

[Marco]

with some care you can avoid using pointers because you can pass variables by reference.

I don't think that makes a whole lot of sense. If I'm passing a pointer to code which might change the data I'd really prefer being able to see it in the code on my screen, rather than having to mouse over or rely on my god awful memory (Google seems to agree with me, that whole style guide is basically anti-C++ though).

[c4757p]

with some care you can avoid using pointers because you can pass variables by reference.

I don't think that makes a whole lot of sense. If I'm passing a pointer to code which might change the data I'd really prefer being able to see it in the code on my screen, rather than having to mouse over or rely on my god awful memory (Google seems to agree with me).

Probably utterly offtopic: yes. Non-const references suck, don't use them please. C's pure pass-by-value-at-all-times is very clean and makes it very easy to know when something will be able to make modifications.

Pointers aren't evil.

[tggzzz]

with some care you can avoid using pointers because you can pass variables by reference.

I don't think that makes a whole lot of sense. If I'm passing a pointer to code which might change the data I'd really prefer being able to see it in the code on my screen, rather than having to mouse over or rely on my god awful memory (Google seems to agree with me).

Probably utterly offtopic: yes. Non-const references suck, don't use them please. C's pure pass-by-value-at-all-times is very clean and makes it very easy to know when something will be able to make modifications.

Pointers aren't evil.

As someone that remembers the endless "casting away constness" discussions in the early-mid 90s, I find http://yosefk.com/c++fqa/const.html wryly amusing.