LanguagesIn a survey I recently conducted of my Embedded Muse newsletter subscribers I tried to understand who is using object oriented programming on their embedded designs. The data I've seen in the past is hardly believable, some polls suggesting over 60% of us use C++. That's logical for PC developers but for embedded?
I think C++ scores highly because many of us employ C++ compilers to generate C code. (Though using "//" to denote comments is great, it's hardly a mark of OOPiness.)
My survey asked a different kind of question: "Please select all of the features of object-oriented programming (OOP) that you are personally using on your current embedded programming project." The 659 respondents replied:
63.7% None of the above
By correlating these figures against processor bus size the data becomes even clearer. 6.4% of respondents who work on systems smaller than 32 bits report using encapsulation. That makes sense, as encapsulation isn't restricted to OOP or OOPy languages. One can encapsulate in C and assembly as well.
About 14% of 32/64 bit developers report using encapsulation but not the other features of OOP. That number is twice that for those working on smaller CPUs, perhaps indicating a more disciplined development strategy on these typically bigger projects. No doubt there's less legacy code as well.
33% of all developers working on 32/64 bit CPUs report using inheritance or polymorphism. Unsurprisingly, essentially everyone employing polymorphism also uses inheritance.
Though C++ offers many other resources, in my opinion inheritance it is such a fundamental part of that language's zeitgeist that it's a pretty good indicator of the spread of OOP into embedded systems. In an informal poll I ran five years ago the number of developers using inheritance was about half of the current numbers which pretty strongly correlated with the increasing adoption of 32 bit processors.
Fourteen respondents complained of problems with performance and code bloat, which they attributed to OOP. These were unprompted emails triggered by the survey, so aren't statistically meaningful, no matter how interesting.
Are you using OOP in your embedded designs? Why or why not? Are you happy with the results?
Jack G. Ganssle is a lecturer and consultant on embedded
development issues. He conducts seminars on embedded systems and helps
companies with their embedded challenges. Contact him at firstname.lastname@example.org. His website is www.ganssle.com.
Using OOP for embedded system is becoming neccessary. Imagine a portable media player with 1M LOC, and 19 engineers and 2 sub-contracting firms working. Its becoming more difficult to design and develop in 'C. So the developer used OOC. The design to implementation was simple. In good old days, embedded systems only meant 8 bit memory starved processors. Now, 32 bit processor using few mega bytes of code, and data are not un-common. I remember Jack answering the wannabe embedded system programmers about the rules of embedded systems. I now think, the gap between desktop programming and embedded systems programming is fading with large embedded systems.
- Britto Edward Victor
OOP benifits have yet to reach my team here.
In my first embedded project, we used completely OOP (C++) and put some limitations on features like virtual functions that could attribute to performance/code bloat.
In my later projects, we used OO design methodology along with the team because the team did not have enough knowledge of C++ to code and debug (and no time and money to invest in training as usual).
These projects made us define how we should code object oriented code using C.
In the final few projects, I work with a much larger and a much "older" team - who have done Structured Programming for ages using C. We are using simple structured design techniques for low level programming and for higher level application and control software, partial OO design is used. But coding is completely 100% in C.
My trend has been a delining use of C++ through the years as compared to your stats :(
I find the only reason C++ is not getting used is due to inertia to even try it out for purposes of evaluation. I dont find any other reason to use C and C alone.
A hybrid should always do better.
- Saravanan T S
Jack, I claim that we used polymorphism when I designed a bunch of user interface functions, in C, to respond to events. The events were: "up key pulsed", "down key pulsed", "enter key pulsed", "initialize", "paint (redraw)", and "tick update (250 ms.)". The simplest kind of function was a generic "menu task", kind of like a Windows "window manager" function. We also implemented a menuing system, with refined menu tasks to offer selectable menus, radio button menus, multi-check menus, and a family of dialog editors to edit gas concentrations, times, dates, and other values. The dialogs had another "polymorphic" interface, whereby the behaviors fit into a structure of functions for "convert binary to string", "convert string to binary", "edit char", "next char", "range check binary", and "display error", all in C, for each of the various editable data types. Are you claiming that none of it was polymorphic, just because it was written in C?
- Keith R. Hill
I think OOP makes sense in some applications, but most embedded systems still use small processors. If you work on 8 bit ones you are not a dinosaur no matter what the magazines imply.
The bandwagon effect is the observation that people often do (or believe) things because many other people do (or believe) the same. The effect is often pejoratively referred to as herd instinct, particularly as applied to adolescents. Without examining the merits of the particular thing, people tend to "follow the crowd." The bandwagon effect is the reason for the bandwagon fallacy's success.
I sincerely apologize, but if you are using C++ (OOP) in your embedded designs... it's because your manager has gotten on the Bandwagon!!! C++ (OOP) is the wrong tool for embedded designs. Everything you need to do, can be done more efficiently with C. You have more control over the entire system, than you do with C++.
- Steve King
we tend to "pick & choose" on a per-module basis as to OOP vs functional programming, where we decide for example that polymorphism is good ( accessing different types of memory using same prototype ) vs the pointer overhead is bad ( writing to a display ). I'd just like to point out to those die-hard OOP exponents that if (as claimed) it is as efficient an idiom, why it is unsuitable for slower processors?
- Ed Straker
Let us bend some myths out there.
--> First of all you can do OOP just fine with plain old 'C'
--> C++ should not cause code bloat...unless you are using STL that is.
--> You really ought not to use STL in an embedded project anyhow.
--> You can get code bloat with plain old 'C'...hmmmm...anyone remember all that old MS Windows stuff??
--> Just as we have had die-hards that still profess assembler to be the one and only, 'C' will fall into this
--> You can obfuscate 'C' just as readily as 'C++'
--> Believe it or not you can still mix assembler with C++ and get away with it!
- Ken Wada
These are just a languages after all. It is all about the way how we prefer to express our thoughts.Take a look to the natural languages over the world - different habits, lifestyles, alphabets...
The use of C/C++ should be probably application driven - the more human related features/interfaces->the more resources->the more need to use higher level of abstraction and expression (C++).
Can someone tell me the ratio of commercial C++ compilers for 8-bit toward higher-bit controllers/processors ???
This herd-effect survey might explain something.
I agree with Steve when he talks about control over the entire system.
I have been using OO approach for design and that makes implementation easier. Coding is strictly in C.
- Monali Bhalerao
One reason responses to these surveys are all over the place is that "embedded system" takes in too much territory.
A lot of designs are single chip 8-pin micros with half a K of memory. Others have embedded PCs with Linux, etc. Yet others are an assembly line that fills a building with dozens of networked computers.
You don't use the same tools and techniques to build a dollhouse for your daughter as you do to build a skyscraper.
- Tim McDonough
I tried once to use C++ in a design that could be classed "hybrid" embedded (PC based). I was fresh out of a course in C++ at a University. The prof had tried teaching the "current" view of "computer science" with C++. The language issues bogged down the course.
After trying to use C++ in real life, I found it easier to revert to C constructs and structure, rather than OOP constructs on the original project. It moved faster.
Since then, I have coded mostly 8 bit microcontrollers in C, mostly in vendor supported toolsets (data acq and networking). I have also coded some PC/Windows using C# . The smaller devices, to me, work best with code written as a set of functions called from a main loop or interrupt driven "structure". Visual Studio forces OOP by design of the tools, built in functions, etc, so is a natural OOP language.
Maybe the future trend is OOP, but I see it happening slowly, and with emphasis on new code on newer, higher bit count processors. Code maintenance is probably best done in the original language concept, structured or OOP.
- Douglas Datwyler
As I read Jack's article I immediately thought about the three biggest embedded systems I maintain. One is in C on a proprietary multitasker, one is in C++ on embedded MontaVista Linux, and one is in C++ on WindowsXP Embedded. Where we use C++ it is first for encapsulation, and second for inheritance, just like Jack's numbers. On the project in C, the reasons we WISH it were in C++ are likewise encapsulation and then inheritance.
Embedded design penalizes sloppy work more harshly than the desktop world. If you take "advantage" of the C++ willingness to create and destroy objects dynamically (my favorite: returning an object from a function, and assigning it to another variable of the same type) you are asking for trouble, especially in embedded. So, don't do that. I find that a basic understanding of what the compiler is really doing goes a long way to choosing what behaviors are acceptable in embedded and what are not.
In general I prefer C++ to C because it offers more tools, but I have a healthy sense of what features of each language to avoid in production code. And like many readers noted, in those projects where we only have C, we do our best to apply the good lessons from C++ anyway.
- Mark Bereit
This survey would be more informative when co-related against programming languages used.
C++ is the most popular choice in the embedded world, but not the only choice. Bu what percentage are using C/C++?
How many people are using Java? It was originally designed to parallel the the C++ ideas of OOP, yet eliminate many of the platform/porting issues and programming pitfalls. Only recently is it being adopted by the real-time community. Is it up to 20%?
Other projects favor strongly typed languages such as Ada. But outside the government and military, who is using these languages?
Still others use a systems design environment like MATRIXx or Simulink as their development platform and rely on some code generation to get lower-level C code which can then be compiled. Likely, these are very large projects.
How about developers of distributed or multi CPU systems. How much more, or less likely to lean towards OOP?
- Joe Sallman
I would choose tools I find best suited for the task.
On 8-bit processor I prefere C with necessary minimum of assembly. It gives better control of resources and resulting code is often more portable. And usually there is not enough RAM to fully utilize OO features.
However on 32-bit device with real operating system I would consider C++ or other OO language, depending on application. If you need multiple instances of same object, multithreading and inheritance, C++ (or Java, etc...) is way to go. It's particulary handy for graphics and communication.
But such design is more custom-built computer then classic embedded device, isn't it?
- Mladen Matosevic
I have read about OOP over the years, but everything I have read seemed to indicate that it would add more complexity to the software I write now using plain old "C" (this is for 8-bit, single chip uC's), with no real advantage. I have been playing around with Microsofts C# Express package, and what I HAVE seen of OOP does not impress me, but on the other hand, I don't write 1 million line programs. In fact, I don't think I've written more than 100K LOC in my entire 25+ year career! (obviously, you can tell I'm NOT a programmer!). I think that small projects, such as the kind I do, don't really need the OOP features. However, I would be interested in seeing an article where someone who is familiar with OOP looks at a variety of small projects and comes up with a reasonable way of deciding if OOP would make a difference.
- Dave Telling
At my work we design mostly large embedded systems (100,000+ lines of code). When I started ten years ago we started using full object-oriented C++. I started with a book called "Thinking in C++" which was good in that it explained what the assembler code would look like when using various C++ features. I would still write interrupt handlers in assembly language and/or C but for large systems C++ is great for the remaining code. For instance using volatile and const to describe objects we can use C++ to read read-only registers and write to write-only registers and have the optimizer turned up to the highest level. In C I always put these in separate files which did not get optimized by the compiler. I agree that you can't use every feature of C++ in embedded systems.
Lately we have been making networked embedded systems and these are mostly written in Java. However we are not doing any register level manipulation in these systems and they are mostly soft real-time.
- Tom Dietrich
If All You Have is a Hammer Everything Starts to Look Like a Nail - fortunately, many of us working with computers, have over 2,500 hammers to choose from this chart: here or there . And it all apparently got started like this, as Genesis 11:1-9 informs: "Come, let us descend and confuse their language, so that one will not understand the language of his companion". More background about the Tower of Babel story can be obtained from this intro here.
However, Jack, I think it is a loaded question you ask. From your research, there is 71.4% of those who use any (some) form of OOP. On the other hand, there is 63.7% who use none of those forms. Marginal difference, considering the vast area of what is being defined as "embedded system", today. It boils down to a choice: Windows CE (or Linux, OS X, any RTOS) written in assembly -and- TV set "remote control gizmo" running Linux and "application is done in Java", -or- the other way around. Purists might argue, but I am not and I won't - the choice is clear. As kolio said above earlier: "[it is] all about the way how we prefer to express our thoughts". Take a crappy thought/idea and implement it in the latest CS concept, run it on the latest HW and it will be - a crap. The language did not morph the thought into something that could not ever be.
- Roger Lynx
An interesting article and comments.
The language matters not, the success or failure relies on the underlying design methodology. Basically how disciplined is your development team (even if it's a team of one) at following the plan.
I have written code for many embedded systems: Java, C, C++, eForth, assembly, ...
The successful ones were the projects where we had a plan and stuck to it.
The failures were the ad hoc design projects, you know the "I can whip that out in a week!" type (turning into two weeks or way more.
As far as C++ OOD goes, if you restrict the use of certain aspects of the language that may kill an embedded system C++ has many benefits.
OOP for OOPs sake is a waste. Use what you feel gives you the most return on you time and effort.
It's a business decision after all.
- Bill Bynum
I find it hard to believe, although I know it's prevalent, that C is the preferred embedded programming language. I can see where using virtual functions, exceptions, etc. in an 8-bit project might exceed your memory/performance constraints, but just using the non-OOP feature like function name overloading and namespaces seems like it would be a big enough win that *all* projects would be written in "C++ as a better C".
- Mike Cox