Making C and C++ play nice in nextgen embedded design
Through most of the past 20 years that I have been involved in embedded systems design there has been a tension between C-language and C++ programmers.
In non-embedded applications on the Web and in mainframes, and in servers, as well as network switches and routers, C++ has become the dominant language. But in most embedded designs, where the focus is on real-time, small footprint, and deterministic operation, C has dominated not only because of embedded programmer conservatism but because C++ was too hefty and slow.
There was also a prejudice against it as an object-oriented programming environment and all that implied in terms of code complexity and all that implied on guaranteed interrupt response times.
But things are changing. Developers will have to figure out how to make C and C++ “play nice” in the same embedded design or the same work environment. There are at least two reasons for this.
First, while the memory space and code sizes of most early 8- and 16- microcontrollers precluded the use of C++, the dominance of 32-bit MCUs in new designs is changing that. Second, the much larger code sizes and operations that embedded systems are required to do, such as operate in a non-sequential and highly parallel multicore environment, is stretching the limits of the C language -- and the programmers that use it.
Included in this week’s Tech Focus Newsletter on “Using C++ efficiently in embedded system designs” are a number of design articles, technical papers, and blogs that may help developers make the transition to this mixed C/C++ programming environment a little easier. Of them my Editor’s Top Picks are:
“A guide to C++ for C programmers,” in which Mark Kraeling has simplified a developer’s decision making process about when and where to use C++ in embedded designs. He does this by breaking down the language’s many features into three broad categories, from most useful and “less expensive” to least useful and “most expensive” in terms of time, effort, and complexity.
“Dive in to C++ and survive,” a first person account from C programmer Christopher White, who takes you through the hazards of learning the ins and outs of the C++ language, the books to read, the tools to use, and how to begin using it effectively in your embedded systems designs.
“Guidelines for using C++ as an alternative to C in embedded designs,,” a two-part tutorial by Colin Walls addressing the well-known barriers to use of C++ by C programmers, providing some guidelines including cleaning up C and an in-between alternative he calls "C+."
Also included is a three part series on the ARM mbed online programming environment, the focus of much activity at the recent 2013 ARM TechCon. After reading this series, attending the lectures and experimenting with mbed on line I was impressed by two things: its ease of use as a development tool, and that although written C++, it is a very efficient and quick way to generate ARM Cortex-M specific C-code for effective real-time and deterministic operation.
While not quite as effective as “learning by doing,” watching and reading how the C++-based mbed tool worked in typical hardware/software designs was a good education in understanding C++’s strengths and weaknesses in an environment MCU developers are familiar with, the C language.
Other articles on Embedded.com that could be useful doing development in the C++ programming environment include:
Also, on Embedded.com, for further C/C++ insights “Programming Pointers” by Dan Zaks is available as regular feature on programming issues. Some of my favorites include: “Poor reasons for rejecting C++,” “C++ classes as abstractions,” and “Virtual functions in C++.”
If you are still prejudiced against C++ because it is an object-oriented programming environment, I suggest you read two technical papers by Bjarne Stroustrup, the creator of the C++ language: “Evolving a language in and for the real world: C++ 1991-2006,” and, “What is C++11?”
“Consider how many programmers have been harmed by believing that ‘C++ is an object-oriented language’ and religiously built all code into huge class hierarchies, missing out on simpler, more modular approaches and on generic programming,” he writes. ”Of course C++ also supports OOP, but a simple label – especially if supported by doctrinaire teaching – can do harm by overly narrowing a programmer’s view of what can be considered reasonable code.”
His commentary in both papers has changed my mind on how the much more work has been done to make C++ a much more friendly environment for C programmers, especially as it relates to embedded systems design.
Embedded.com Site Editor Bernard Cole is also editor of the twice-a-week Embedded.com newsletters as well as a partner in the TechRite Associates editorial services consultancy. He welcomes your feedback. Send an email to firstname.lastname@example.org, or call 928-525-9087.