Why does ARM mbed rely on C++? Is C++ the future?

[nctnico]

- C++ is slow. (real-time, soft-realtime, etc.)
- C++ produces bloated machine code.
- Objects are large.
- Virtual functions are slow.
- Abstraction leads to inefficiency.

Is C++ the future for embedded?

Yes. Inefficiency is the future. If you don't like inefficiencies produced by C++, get over it. By the time you make peace with C++, there will be something even less efficient - Linux, Python, whatever. The whole generation of designers (software and hardware alike) grew during the period of tremendous growth in hardware technologies. During this period, a strategy of getting quickly into a newer cutting-edge technology (as opposed to creating solid efficient designs for existing technology) was winning big time. Thus, if you want to be ahead, jump as far as you can. When you consider C++, don't think if it's efficient or not, rather be afraid that it might be already obsolete.

These discussions remind me of the C versus assembly discussions from a few years ago. What people tend to overlook is that projects become more complicated while the time to create the software has become less. Usually a lot of time is lost on debugging so if you can use a language which allows to prevent mistakes like passing variables by reference instead of a pointer, having OO built into the language instead of re-creating it, make software portable, etc, etc you can make a product cheaper. Hardware is cheap. Time is not.

The next thing we'll probably see on microcontrollers are script based languages like Python or Lua. Not because they are space efficient (speed isn't much of an issue) but because they allow to produce less buggy code quicker because people can concentrate on the problem at hand and not deal with low level stuff all the time. For example: C/C++ require you to do things like range checking yourself and be aware of endianess, pointer arithmetics, etc.

[andyturk]

Of course, you may hope that the efficiency era may return, and this might be indeed the case, but I wouldn't count on that being any time soon.

The "efficiency era" (nice term!) is still here for some of us. If you're working on a wearable or other "IoT" device, power consumption is important and uA matter a great deal.

C++ is just as good as C at low-level efficient code, and vastly better than plain C at exposing problems at build time (rather than run time). IMO, C++ is a *better* tool for embedded development than C for that reason.

[Karel]

[JPortici]

and what happened between 2016 and 2018?

[ataradov]

and what happened between 2016 and 2018?

People gave up on programming altogether and all went into marketing.

[JPortici]

- C++ produces bloated machine code.

enjoy.
of course, the result depends on the compiler.
i don't use C++ because the MCUs i use the most only have C compilers, otherwise i would certainly be happy to use some of its features.

and what happened between 2016 and 2018?

People gave up on programming altogether and all went into marketing.

  more work for us

or maybe they siwtched to power-point as their main language?

[NorthGuy]

Hardware is cheap. Time is not.

You must admit hardware may be a little bit expensive:

https://www.digikey.com/product-detail/en/xilinx-inc/XC7V2000T-G2FLG1925E/XC7V2000T-G2FLG1925E-ND/3981901

(which is far from being the most expensive one).

The next thing we'll probably see on microcontrollers are script based languages like Python or Lua. Not because they are space efficient (speed isn't much of an issue) but because they allow to produce less buggy code quicker because people can concentrate on the problem at hand and not deal with low level stuff all the time. For example: C/C++ require you to do things like range checking yourself and be aware of endianess, pointer arithmetics, etc.

I don't think it has anything to do with buggy software. Perhaps, this is because you can hire (admittedly) cheaper Python programmers who are not aware of endianness and pointer arithmetics. The less they aware of, the cheaper they cost. Nobody knows who your programmers are, but everyone sees the hardware you ship. Marketing teaches us that it's better to cut costs on something invisible, right?

John Hammond is certainly fictional, but he explains the problem well: "no expense was spared", yet no money (or effort) spent on hiring a decent software programmer. As you remember, in the end, one bad programmer caused the whole enterprise to collapse.

[NorthGuy]

As far as I'm concerned there is no reason for C to be so popular these days. It is well past it's best before date now.

It might be. Xilinx has an engine which lets you program FPGA in C. Not to mention MicroBlaze. Thus the growth in FPGA popularity must reflect on the popularity of C.

It is all bogus anyway. I don't think there are many C programmers who would google "C programming".

[nctnico]

As far as I'm concerned there is no reason for C to be so popular these days. It is well past it's best before date now.

There is a good reason: C and C++ are very standard and very portable.

[C]

There is no compiler for ____

Seen this excuse many times over the years.
Foundation is a messy hard to parse language with poor rules.
Simple can be powerful an create great programs. messy foundation just leads to more and more problems.

If all the compiler writers time is spent fighting foundation problems, how much time is left to add smarts.

Got to compile to machine code.
Really, Memory speed has always been a bottle neck.
With storage speed more so.
Think of X bytes of machine code Vs X bytes of info to small program in cache.
Best choice would be having a choice as one size does not fit all.

If the language does not define things the compiler can not assist.
Simple things line this line of code is adding a temperature to a pressure.
But compiler does not know it's a  temperature  or pressure if a language does not define types to assist in error checking & programmer does not use them you get wasted time & bugs.

If you study history, C started as an assembler replacement.

A lot of the newer languages think they know better and fix a problem by forcing one way. The world is messy an wants options. Some like more then one, I like many displays.
Many works great with groups.
 
Current trend looks to be making computer work in human and not computer. To/From human takes time. To human & from human should be a used to interact with the human.
Is it so hard to program show computer & show human and pick which by detestation?

There are many examples where things were different.
Operating systems have been written in high level languages where you would be hard pressed to do same in C or C++ in same time, with as few errors and machine speed.

Simple fact is the more a programmer inputs into a program the more a compiler could help.

If all you have learned and worked with is "C" then understanding the benefits of something different is hard.

There are bad things in hardware also.
Many things are binary ratios. A binary value to the right of decimal point. You do what's easy for you to do and work around problem instead of fixing hardware & languages.

Think about current "C" programmers, should they protect their mountain or assist in building a new one?
 

[5upercircuits]

Thank you everybody for all the educated and detailed answers. Awesome!
I'll conclude all statements and compare the different opinions.

Things that most people agreed upon - usefulness of C++ in embedded:
1.1 C++ seems to have useful and superior features for embedded, the problem/difficulty is to learn/teach people how to use them.
1.2 Using C++ in embedded without a proper knowledge basis can create bad embedded code.
Conclusion of the two points listed above: The problem seems to be that when you compare C and C++, C++ has much more powerful tools that can become quite dangerous. However, in C most amateurs will just play with simple small code and never even reach the code base that professional C software engineers are handling on a daily basis. When amateurs start to use C++ then they play with powerful tools that they might not fully understand and accidentally create a basis for bad code.

Regarding mbed and Arduino, most people seem to agree:
2.1 mbed and Arduino do have a place
2.2 mbed and Arduino are good if you just want to get a fast prototype working or if you're just starting out/learning embedded development
2.3 mbed and Arduino are not suitable if you are looking for customization, flexibility, scalability

Regarding "Is C++ the future" we are divided:
3.1 Some people believe that C++ is crap altogether and should and will slowly vanish. Not only in embedded but in general
3.2 Some people believe that today's embedded projects have become so complicated and advanced that we will need a new programming language other than C (but maybe not C++)
3.3 Some people seem to be completely ok with using C++ for embedded and are also not looking for other languages.
From what I've read, I believe that a change to a different language is likely. We do have a demand for more advanced features.

It kind of feels like with C you get a ten pages book and then you gotta write the remaining 90 yourself (usage patterns, encapsulation, etc.). With C++ you get a 500 page book but you gotta memorize that you are only allowed to use 100 randomly spread pages. In my opinion both choices are not ideal. One language lacks crucial features and the other is overloaded with features that are not feasible for embedded development. Maybe in the future we should/will have a language that is more optimized for embedded only.

Conclusion, I would say that 3.2 will happen in the future. Maybe mbed and Arduino also serve the purpose to get more creative and try out different stuff. Maybe that is also the reason why ARM decided to develop mbed in C++ to encourage change?

Note: I'm not a journalist or anything of the sort, just wanted to conclude all the answers a bit to create a basis for further discussion

[tggzzz]

5upercircuits, that's a pleasantly succinct, accurate and nuanced summary of the various PoV I wish more postings were like that!

I would modulate your statements by adding that:

• languages, like scientific theories, are only replaced as their practitioners retire => C/C++ will be around for a long time. There are other languages being used for embedded systems, but it remains to be seen how they will progress. I don't expect an answer before I die
• with C++ you have to ensure that all developers and libraries and compilation options are using the same subset of C++ and usage patterns, or at least not subsets/patterns that fight with each other
• a couple of decades ago the C/C++ committee was facing a dilemma: should it become a systems/embedded or general purpose language. Either would have been acceptable and internally consistent. They tried to do both, and IMHO failed: Java is the general purpose language, and C++ is too arcanely complex and poorly specified to be a good embedded language

[Karel]

Does nobody wonder why in operating systems and drivers only "C" and assembly is used? There are many good reasons to stick with "C".

[hans]

What is dangerous about C++ is that it is very easy to create bad code. One template or class that uses run-time polymorhism called in an interrupt or other critical section could explode the binary size and execution time, thus killing performance. In embedded projects that often renders the final executable useless. It only requires 1 slip up of someone in the team (that is perhaps not very familiar with the platform and it's limitations) to do this.

What I find ironic is that C++ also offer tools that should allow better scaling of software projects and teams, yet alot of them are more dangerous. You cannot expect everyone on a team is as qualified or sharp everyday,  and you only need 1 screw up..

So what do we do? Basically all we're doing in embedded is defining "safe subsets" of the language that we should use. Other subsets should not be used, but we cannot go as far as changing the compiler/language standard to remove library functions, keywords or constructs. We end up with a compromise; and for some the compromise is better in C++ or C.

I think what is an upcoming in other fields (e.g. digital logic design) is to use EDSL (Embedded Domain Specific Language) to describe your system or software in a high level language, where there are no "illegal subsets". All operations you can perform are legal and have as little side effects as possible. This also simplifies the language as there is less to worry about.

Drawbacks:
- Arguably there is some overhead in creating only a safe set of operations, which is sometimes not acceptable in embedded code. This also relies partially on how good the compiler is for your problem; e.g. can it perform optimizations or transformations on the code to mitigate this.
- EDSL are intended to be small and thus application specific; which means that new "languages" are invented for each case. That introduces the problem that one needs to learn more simple languages. It could be possible, but it seems not something a lot of people (especially in industry) are interested in.
- To some degree, creating an EDSL with the use of metaprogramming in C++ is possible. However as said, investing the time first to create "safe" libraries could take a considerable amount of effort, perhaps not worth it to small teams. But in C++ you do get benefits from e.g. the STL and other static library variants, which avoids that one is implementing a circular buffer for the 100th time..


For me, I think C++ is making a better trade off than C, but different opinions always will exist. I think if there ever will be a language that's "perfect" for embedded code with enough baggage (e.g. RTOS', protocol stacks and libraries) available, there will always be legacy projects and people convinced they don't need better tools.

[andersm]

Does nobody wonder why in operating systems and drivers only "C" and assembly is used?

Counterexample: IOKit. Some of the designers have later said that the decision to use only a language subset was a mistake, and it wouldn't actually have been difficult to support the full feature set. AFAIK NeXT used Objective-C for drivers.

[tggzzz]

Does nobody wonder why in operating systems and drivers only "C" and assembly is used? There are many good reasons to stick with "C".

The assertion is false, and there are many many good reasons to leave C/C++. You may not know them, but that is a characteristic feature of the myopic C/C++ community. Fortunately youngsters aren't that hidebound, and alternatives are appearing.

One of the things that attracted me to Java was Gosling's original whitepaper way back in 1996. In it he discussed the various features that had been shown to work in other environments, why he rejected some and why the ones he included complemented each other.

In contrast the C/C++ community resolutely insisted on going their own way, not understanding the consequences of all the misfeatures they were throwing together in the next versions of the language. (One example: the committee didn't believe that a valid C++ program could cause the compiler to emit the never-ending sequence of prime numbers during compilation - until somebody rubbed their noses in it!)

[C]

Does nobody wonder why in operating systems and drivers only "C" and assembly is used? There are many good reasons to stick with "C".

Not hard to say that above is not a true statement.

A lot of papers have been written.
Think actions do speak loud.
HP Pascal/Modcal was early 1980.

Left out "USCD Pascal Operating System" that also existed back then.



Oberon (operating system)
https://en.wikipedia.org/wiki/Oberon_(operating_system)

Granted this is research.

But

Hewlett-Packard used pascal & modified pascal internally for many years.

HP 3000
https://en.wikipedia.org/wiki/HP_3000

The PA-RISC based HP 3000's operating system was written primarily in Modcal, HP's extended version of Pascal.

HP Modal was a big thing inside some parts of HP.
HP series 200 of which the HP9826 model is one of series, had all most all code written in Modcal.
The System & the languages were written in Modcal with very little Assembly.

Need to remember that Modcal foundation is Pascal or an extension of Pascal.
It is a fact that HP Pascal for many systems was actually the internal Modcal compiler with the ability to set a compiler switch removed.
Back then a lot of products were made for internal use in HP and only later sold to public.

HP did not tell the world what had a foundation based Modcal. Even if you looked at the code, the change from pure pascal was very small.

So how many others used other than "C" and thought of it as internal secret?

When you have a good compiler that understands Pascal rules that do not exist in "C", It is not hard to change source syntax(what you type)  to have a different input syntax.

This above is all pascal like languages.

Forth (programming language)
https://en.wikipedia.org/wiki/Forth_(programming_language)

This was often used for embedded systems.
If what I read is correct, it is becoming the initial boot language for PC's

An this does not count the many language X to "C" output methods.
Gain the benefit of better source checking and still use "C" as final step when needed.

What is really needed is not just a compiler, but an IDE that can do source syntax & language rule checking while editing the program.
The higher level languages often have many ways to look at source. These views also need to be a part of the IDE.

Sad to say but "C" has little capability to adapt to Newer/other things with out creating a bigger mess.

And most if not all of "C"'s problem areas have been fixed more than once. Changes that can not be added to "C" with out breaking existing code.

Little things can make a huge difference to the compiler writer.
Poor syntax is a big one.

When you remove the "FORWARD" key word from pascal this is a huge change.
With  "FORWARD" you can have the headers for procedures or functions before the actual source code for the procedure or function.  You can have a two pass compiler. This is where the source code is read two times to get code output. This also lets compiler function with less memory as only global & current is needed.

With out forward you get a global find problem where syntax matters.

With good foundation you can add to language.
You could have "Interrupt" function where hardware directly calls language function and no middle hidden code needed to get a "C" function to run.

It's a simple fact that the more you type, The better job the compiler can do. The more the compiler can help finding errors.
Type more or input more and save time later in process.

 

[rstofer]

The assertion is false, and there are many many good reasons to leave C/C++. You may not know them, but that is a characteristic feature of the myopic C/C++ community.

And go where?  ADA ain't it!  Neither is Java.  I haven't seen any OS code written in anything other than C.  Sure, I lead a sheltered life but it seems to me the language decision has been made.  Whether aspects of C++ are worth importing is debatable, everything that needs doing can be done in C.

I will concede that STL looks attractive.  I don't like having to code up yet another circular queue so maybe I'll go back to one of my projects and try the library.  I just worked through one of the sample programs and it works quite well.  I need to get the linker map to find out just how much space the queue code used.  The overall binary is about 70k and that includes stream output.  There are many platforms that don't even have 70k of RAM!

I have a question:  WHERE did the library put my queue elements? On the heap, I imagine.  I want them put in a specific area of memory.  The LPC1768 has two blocks of memory devoted to buffers and I want my queue data in one of them (16k block).  Therefore, the  queue has to be defined such that it consumes no more than 16k and it has to be at a specific area in memory.  I wonder how I make that work...  It's pretty trivial with GCC.  Oh, and I want the maximum queue size pre-allocated - really an array of chars (in one case) with a head and tail pointer.

You know you are using the special buffers when the RAM map shows 45.1k used out of 32k available.

I remain unconvinced!

[nctnico]

The assertion is false, and there are many many good reasons to leave C/C++. You may not know them, but that is a characteristic feature of the myopic C/C++ community.

And go where?  ADA ain't it!  Neither is Java.  I haven't seen any OS code written in anything other than C.  Sure, I lead a sheltered life but it seems to me the language decision has been made.  Whether aspects of C++ are worth importing is debatable, everything that needs doing can be done in C.

I'm sure that the Linux kernel will be smaller, faster and easier to maintain if it is rewritten using C++. It is all OO already anyway so why not use a language which supports it and can be better optimised by using compile time linking instead of runtime (as it is happening now).

I will concede that STL looks attractive.  I don't like having to code up yet another circular queue so maybe I'll go back to one of my projects and try the library.  I just worked through one of the sample programs and it works quite well.  I need to get the linker map to find out just how much space the queue code used.  The overall binary is about 70k and that includes stream output.  There are many platforms that don't even have 70k of RAM!

I have a question:  WHERE did the library put my queue elements? On the heap, I imagine.  I want them put in a specific area of memory.
I remain unconvinced!

You need to read more! If you write your own low level allocator you can use any kind of memory you want AND use the library.

[tggzzz]

The assertion is false, and there are many many good reasons to leave C/C++. You may not know them, but that is a characteristic feature of the myopic C/C++ community.

And go where?  ADA ain't it!  Neither is Java.  I haven't seen any OS code written in anything other than C. 

Jave certainly not It is a general purpose language. C++ could have aimed into that space, but chose not to - and is now caught between a rock and a hard place.

I suspect that one of your limitations is that you aren't considering RTOSs.

ADA is good for embedded, certainly at the  RTOS level.

Then there are the RTOSs that are implemented directly in hardware, e.g. the rather good XMOS xCORE processors running xC.

In addition to the others noted by "C" above, I'll point to Smalltalk-80 and derivatives, where "80" means 1980

Sure, I lead a sheltered life but it seems to me the language decision has been made.  Whether aspects of C++ are worth importing is debatable, everything that needs doing can be done in C.

I will concede that STL looks attractive.  I don't like having to code up yet another circular queue so maybe I'll go back to one of my projects and try the library. 

Just so. Tell me about it

One of the things that pleasantly surprised me about Java was that within a year of release (by early 97) there were all sorts of complex libraries that plugged and played well with each other. That was something the C/C++ community had failed to achieve in a decade! That's telling.

From what I can work out, good luck trying to debug embedded applications using the STL and exceptions!

I remain unconvinced!

I'm unconvinced about what will supplant C/C++ in embedded applications, but something will.

[SiliconWizard]

I would add one point to what we all said.

I personally think that any non-standardized language should not even be considered for professional work.
And whereas C, C++ and ADA all have robust standards that have been evolving on a regular basis for several decades now, this is far from being the case for a lot of other languages that have been mentioned here.

If anyone can mention any language (other than the 3 above) that has a good standard and is adapted for embedded development, please do so!

[rstofer]

Left out "USCD Pascal Operating System" that also existed back then.

I have a LOT of experience with UCSD Pascal.  The language compiled to P code that was interpreted by machine specific code written in assembly language.  Every bit of the low level code was written in assembly. 

This was great for portability.  All that was required to port the system to a new platform was the low level interpreter.  But it was written in assembly code!

So how many others used other than "C" and thought of it as internal secret?

When you have a good compiler that understands Pascal rules that do not exist in "C", It is not hard to change source syntax(what you type)  to have a different input syntax.

This above is all pascal like languages.

I love Pascal!  I used it one time to build an 8051 control system.  It was elegant.  The code just looks nice on the printed page!

Forth (programming language)
https://en.wikipedia.org/wiki/Forth_(programming_language)

This was often used for embedded systems.
If what I read is correct, it is becoming the initial boot language for PC's

A long time ago I was writing  CP/M BIOS drivers for SCSI drives.  The drive manufacturer used Forth for all of their final test processes.  This was neat because the code was built from the bottom up (by definition) and new tests could simply be piled on top of the existing code.  A completely different kind of test might take one or two lines of Forth.

In one implementation (maybe all), a code block had to fit on the screen.  The idea was to be able to see all of the function code without having to scroll through multiple pages.  If you couldn't define a function in one page, you didn't understand the problem.

Forth is perfect for people who love RPN.  If you think in terms of stacks, Forth is the language for you!

Forth is not quick and I don't see any application for it in an embedded device.  My toaster will work fine with C code.

The reason C exists is that it is as close to assembly language as necessary while still providing a high level syntax.  It works at the hardware level and, AFAICT, it does it better than any other language.  We're talking bit-twiddling, not solving world hunger.  We had a language for world hunger (PL/I) but it was too far ahead of its time.  It came out in '64 and is still in use although it certainly has its detractors.  COBOL came out 1959, so it's only a few years older than PL/I and it is still in use.  They even added objects!  Fortran came out in '57 and is still in use.  C is a 'johnny come lately' language as it came out in '72.  I've been writing code since 1970 - starting with Fortran and continuing to use it to this day.

[cstratton]

limited use of some C++ features like the mostly-static use of objects (like are used in Arduino code) to be kind of nice from a writing-the-code perspective.

This is one of the points where trying to use mbed in a serious project started to cause difficulties.  Unfortunately, the initialization for those objects runs before main(), so if you need to do some pre-setup before they run, you end up having to modify the lower level startup code.  In contrast, in a C project you typically only start configuring hardware peripherals in main()

The way some of the configuration is done is also a bit inconsistent - going well out of the way to maintain runtime flexibilty in some places, making large and mostly undocumented assumptions in others.

Serial1.write("stuff\n"); is much preferable to mucking around with structs.

You typically only do substantial "mucking around with structs" when configuring hardware peripherals.  Writing to them is typically just a function call regardless of language.

Last I checked mbed's serial input routines were not interrupt/buffered, even optionally, and you actually had to implement your own ISR and buffering.

Using mbed did get the project sort of working quickly, which proved the idea.  I think in the end though getting it to actually work right required more time behind the scenes figuring out and fixing what was actually going on, than writing against a lower level library would have.  Granted, time early in a project when you are trying to demonstrate viability can be more valuable than time later.

[SiliconWizard]

I love Pascal!  I used it one time to build an 8051 control system.  It was elegant.  The code just looks nice on the printed page!

I've always found Pascal and its derivatives very elegant. I cited Niklaus Wirth in my first post, for whom I have a deep respect and think he's not received the consideration he deserves.

As a relatively recent derivative, there is Oberon(-07). It has never really taken off but it's very elegant and concise at the same time. One company is selling compilers for ARM MCU targets: http://www.astrobe.com/Oberon.htm

I would not consider it for several reasons, the first being that it's not standardized as I said before, and also that there are almost no tools except this one, but it's still interesting to play with.

It features modules and a no-nonsense object orientation model, and is very easy to learn.

[rstofer]

I suspect that one of your limitations is that you aren't considering RTOSs.

There are many RTOSs but I'll bet the majority are written in C.  I know that FreeRTOS is written in C and it seems to be pretty popular.

I'm unconvinced about what will supplant C/C++ in embedded applications, but something will.

Why?  What we have works fine, there's a ton of code in the wild and there's no motivation to change just for the sake of change.  If anybody cared, there would be a lot more Ada being written.

As to standards:  What standards?  They keep moving the goalpost, adding features that seem 'gee whiz' but aren't really necessary.  C++98, C++03,C++11,C++14,C++17 and the yet to be released C++20.  C++ is a moving target!  Of course, C is no better.  Once a language has an ISO committee, they have to earn their keep by changing stuff.

We know Unix is written in C, Linux is written in C, how about Windows?