The latest Embedded Systems Design features an overview of their annual comprehensive programmer's survey. ESD (an unfortunate acronym for a hardware journal) has offered the same survey for the past few years to engineers and programmers in both the USA and Europe, seeking info on their current and anticipated needs, projects, tools, and the like (N>1000 for the past three surveys). There are many useful tidbits in here but one in particular caught my eye, and that's the trend in development languages used.
Embedded programming is considerably different from the more typical desktop application programming familiar to the average CS major. What we're talking about here are those myriad microprocessor/microcontroller based systems that tend to be invisible in our lives such as the guts of cell phones, MP3 players, and so forth. Although an awful lot of code may be required for these applications, obviously, these devices cannot be developed and programmed in the same way as, say, a word processor. Due to cost constraints (and thus memory and computation constraints) on the chips used, embedded work tends to be "closer to the metal" and is often done by graduates of electrical engineering and technology programs than by classic computer science grads. For example, it wasn't that long ago that a majority of development was done in assembly language.
So what are the recent trends? The ESD survey compares results over the past three years. First, assembly language has been fairly stable at 7 to 8 percent of projects. BASIC has managed to garner 1 to 2 percent (although the article doesn't mention it specifically, I assume that this is from items such as the BASIC Stamp microcontrollers from Parallax), and all other languages with the exception of C/C++ cover less than a few percent each (such as XML, MatLab, LabView). Even Java is in this category, slipping from 3 percent in 2005 and 2006 to just 1 percent in this year's survey.
The lion's share of development is in C and C++. No surprise there, but the interesting thing is that C++ is actually losing ground. 2005/6/7 saw C++ at 26, 30 and now 22 percent, while C has grown from 51 percent in 2005/6 to 63 percent for 2007. I find this particularly interesting. As an old hand at C, I was never overly enthused with C++ (I agree that there are certain advantages but I have maintained for several years that C remains superior for embedded use). The folks at ESD offer a few ideas why this trend has occurred including the possibility of a larger number of projects being outsourced, but maybe some of it has to do with finding the right tool for the job versus listening to marketing types.
- Log in to post comments
I'm an embedded developer who programs in C and assembly. For the devices I use, C++ compilers adhere to some unknown level to a standard, whereas C compilers are ANSI or very close to it. Another big factor is that C++ can lead to a lot of implied execution of code whereas C is fairly explicit (no virtual functions, no operator overloads etc.).
The nature of my projects also do not lend themselves to OOP.
Boronx, have you done any direct comparisons between code size or execution speed between C and C++ on any of your projects?
Jim Fiore said:
> Boronx, have you done any direct comparisons between code size or
> execution speed between C and C++ on any of your projects?
To answer a question addressed to somebody else:
This varies massively from project to project, team to team and compiler to compiler. I have found that using all the features of C++ (especially the STL) causes a large increase in executable size. Using C++ as "OO C", in my experience, costs fairly little in executable size and nearly zero in speed.
Bad C++, of course, can be terrible. One feature which is a particular favourite for bad code is templates. They can be a really cool feature when used correctly, but cause amazing bloat when misused.
Like so many engineering problems, the answer to "C or C++" is "it depends."
I agree, Marc. Your comments remind me that I have long felt that it was really unfortunate for the embedded world that C++ turned out to be so much more than "C with classes". If 8- and 16-bit compiler vendors had offered, early on when OOP & C++ were starting to make a buzz, a language that was C with a few very simple and behaviorally well defined extensions, namely: *simple* classes (i.e. no virtuals/polymorphism, no templates), inline funcs (fix weaknesses of macros-with-args) and maybe the double-slash comment (just "because"), then this language (C+? "Classified C"? -- whatever they called it) would have come to dominate the embedded space.
More safety, a hand-up in controlling monstrous method and var naming, and zero cost to code size and speed and nearly zero negative impact on readability of generated assembly code (well, assuming the compiler vendors would choose nice naming conventions) -- what's not to like?
It seems like when "Embedded C++" came along, people had already been burned, and IIRC, EC++ had a complex spec. I suppose there was also a lag in attractive (price and performance) debug tools.
They could even have included multiple inheritance (optionally?), which poses a small but manageable risk for the unsophisticated user.
Seems such a shame.
Another embedded developer here...
I concur with Marc B's comment, "it depends". C++ for OO C can be very time and/or space efficient, and I've found it's the programmer, more than the compiler or project, that matters. The project's architecture also plays a role, as does the mapping between that architecture and the software implementation. It seems to me many projects run into un-necessary difficulties simply because the software objects are not appropriate for the project, leading to convoluted and/or bloated OO, be it C++ or some other language.
Incidentally, the original C++ was called "C with class", and was essentially that. It was elegant, both as a language and in its implementation. (In fact, I still have Bjarne Stroustrup's original BTL (Bell Labs) TR (technical report) on C with class someplace; as I recall, it's only about a dozen pages and covers the entire language.)
The aforementioned issues with code size and undependable execution speed of most of the more esoteric features of C++ certainly has a lot to do with it. The other side of the coin is that most embedded projects really don't have that huge a codebase, and don't really gain very much maintainability or development speed using C++ as compared to plain C.
There was some sounds a while ago about the next C standard adding simple objects to it - essentially creating the "C with objects" language that quite a lot of people have been wishing for. Anybody know more on that?
Well put, Janne. It always seemed to me that some of the pluses of C++ (no pun intended) were lost on many embedded projects but the minuses might still creep in. Of course, the programmer's knowledge along with the sophistication of the compiler needs to be weighed in as well. To illustrate this to my students using straight C, I would show them the assembly output of the same code snippet written two different ways. It was just an implementation of strcpy(), the first using register pointers with post increment as in while( *dest++ = *src++ ); and the second using array access via an index from a for() loop. This was on a 68k platform and the results were eye-opening, the second version maybe three times larger and proportionally slower. Of course, copying a string is no big deal, but if you're using the same techniques to copy over edited chunks of PCM audio that are a few hundred thousand sample points long...
Regarding C with classes, I have heard nothing about this lately, but somewhere buried in my office is a video tape of Stroustrup giving a presentation on it!