embedded software boot camp

Observations on the relevance of C++ to embedded systems

Thursday, September 10th, 2009 by Nigel Jones

My fellow blogger Mike Barr recently wrote an article entitled ‘Real men program in C’. Given that his blogs are cross posted at embedded.com, it was soon picked up by reddit et al and the usual language wars started – with all that these wars usually entail. Personally I don’t get very worked up on this subject and so I didn’t participate. However it did dove tail rather nicely with a conversation I had recently with Dan Saks. I had asked Dan for his thoughts on the difficulty (impossibility!) of inlining global functions in C. The conversation was interesting in its own right, but at the end Dan posed the question ‘Why don’t you program it in C++?’ (since for the uninitiated, C++ allows you to quite nicely inline a class’s public functions). I’ll leave for another day, my response and also my thoughts on C++. However, it did get me thinking a lot about this issue.

Now although I have many thoughts on this topic, the one that I’d like to share with you today is my observation that there is an incredible dearth of example C++ code for embedded systems. What do I mean by this? Well like most of you, I regularly download example code from vendors sites – and it’s nearly always written in C and not C++. I’d previously explained this away by assuming that it was because I do a lot of work in the 8/16 bit realm, and that smaller processors are more likely to be programmed in C than C++. However, yesterday I attended a seminar put on by TI. There were several things of interest in the seminar, including TI’s proprietary RF networking protocol SimpliciTI and also their recently acquired Cortex 3 line from Luminary. The FAE encouraged us to look at the code that was available for both of these entities – and so I did.

What I found is that the SimpliciTI code is all written in C as was all the Luminary code I looked at including their impressive graphics library. Hmmmm thought I – is this an aberration or is this norm? For my next stop I went over to the Micrium web site where they offer a fine array of products including an RTOS, a variety of protocol stacks, a graphics library and so on. All the ones I looked at were written in C. Same story over at Segger. OK, thought I, what about the compiler vendors? A sampling of the code examples at the IAR and Keil websites (for their respective ARM product lines) showed them to be all in C. Finally I headed over to the Greenhills website to check out their enormous Networking and Communications product line. I chose half a dozen products at random. In all cases where the language was specified, it was ANSI C.

Is this a true random sample – of course not. However it does suggest to me that the industry hasn’t exactly embraced C++. Now it’s debatable whether the tool vendors and silicon suppliers should lead the industry or whether they should reflect reality. Regardless of your perspective on this, it’s clear to me that I’ll know C++ has been embraced by the embedded community only when the majority of the publicly available code is written in C++. Personally, if it hasn’t happened by now, I don’t think it’s going to.

Home

4 Responses to “Observations on the relevance of C++ to embedded systems”

  1. Mark says:

    I also doubt that we will be flocking to C++ as an industry. I would like to point out one thing that you didn't mention, though: You can easily use those C libraries in C++, but the opposite is more challenging. Yes, it's certainly possible to create a C++ lib that exports to C, but there are many more potential hiccups and you're now requiring a C++ compiler instead of allowing either. So if you are a library creator, which are you more likely to develop it for?

  2. Nigel Jones says:

    Agreed. However what I think is pertinent is that the marketing issues you cite have greater pull than the benefits of C++. I find GreenHills to be particularly interesting. They have hung their hat on reliability and security and seem to target almost exclusively 32+ bit processors, and yet despite this (some of) their products are still written in C. Clearly they don't seem to think that writing in C++ improves their product enough to make up for any potential shortfall caused by potential customers walking away because they program in C.

  3. Anders says:

    Hi Nigel,All other c/C++ issues aside, it is interesting that you mention Greenhills and reliability/security; there is a very strong opinion *against* C++ in the high integrity business and there are mainly two (broad) arguments:1) The language is so complicated that there are obvious risks that you will shoot yourself in the foot in a very spectacular way.This is true(!), but most of these arguments stem from misconceptions about how the language really works when it comes to the inner workings of (dynamic) object creation.2) C++ compilers for cross compilation to embedded cores are immature and very complex animals, so trusting such a compiler with your safety critical code is not a good idea without extrem caution. (I'm obviously not going to comment on that… 🙂 So there is strong advice against C++ in the high integrity field. This might start to change now that the MISRA guidelines on C++ are out in the wild.But it can also be interesting to note that C compilers for typical embedded cores have been around for at least 25 years and there are still quite a lot of programmers out there with a strong opinion against C…

  4. Nigel Jones says:

    I find your comments quite fascinating Anders. On the one hand there is the mantra that C++ prevents many of the common errors found in C (for example by requiring constructors to help mitigate against uninitialized value problems), and that as such it is a superior language for high integrity applications. Then on the other hand there is your observation that the language is perceived to be so complicated that a developer can inadvertently shoot himself in the foot – thus potentially compromising the integrity of the application.I think this reinforces what I've felt for a long time regarding the C / C++ wars. My preference when it comes to maintaining code (which is the real acid test – writing is trivial by comparison) goes as follows:1. Very well written C++2. Very well written C3. Poorly written C4. Poorly written C++I'd be interested to know if any of the other readers of this blog agree with this hierarchy – and if so whether they think it may also explain the dearth of C++ example code out there.

Leave a Reply