Design Article
Dive in to C++ and survive
Christopher White with Kelly Deltoro-White
2/16/2009 5:40 PM EST
When I ran into problems with my first major C++ project, however, I discovered that each new "solution" just slammed me into another roadblock. I needed answers. But all I got was frustration.
And it looks like I'm not the only one. According to the 2008 Embedded Market Study, C++ use has lagged behind C and the numbers have not significantly improved. In 2005, only 26% of those surveyed used C++ (compared to 51% with C) and while C use rose about six percentage points over the next three years, C++ use fluctuated before it settled into a mere three percent increase.
No surprise, given the frustration factor, but the fact of the matter is C++ is an amazingly useful tool in embedded design. But before you can use its awesome powers, you just have to wrap your mind around one little detail: C++ isn't a programming language; it's a worldwide research project running about in disguise.
Here's the lowdown. Reading compiler manuals will only get you so far. The bulk of C++ is documented in papers, presentations, and (most importantly) the experience of its users. In fact, the range of legal C++ code is so wide that you have to write idiomatically to be understood by other programmers (see References [2, 3, 4, 5]). You want to be good? Then you've got to get involved.
So, come on. Let's dive in and get our hands dirty.
Many of us remember when the number one (frustrating) feature of C++ was that its portable code wasn't actually portable. These days, C++ is much more portable on desktop and embedded platforms, but portability still isn't a given [7].
Your best bet? You got it - head to the library! C++ library authors and vendors are C++'s QC department. To see how your compiler measures up, start with the Boost library regression test summary [8] and the Dinkumware standard-library manual [10].
For many platforms [11], GNU GCC is a good bet for a conforming compiler with a price that just can't be beat. If there's no C++ compiler for your platform, try Comeau C++ [9]. It claims to track the standard very closely, and compiles C++ to C for your favorite toolchain. While I haven't tried it myself, the reviews are good.
The compiler's main business is managing names, not generating assembly. The code int i; doesn't necessarily allocate space for an integer. Instead it gives the name i a new property: it can refer to something of int type in the current scope.
This matters when you use overloading and templates, when what a name refers to depends on the context in which it is used. Template matching and overload resolution are designed to make the common cases Just Work, but this can lead to confusing errors about ambiguous function calls (Appendix B in [11]).
Partial specialization, where a template can behave differently for subgroups of its arguments, adds even more power with its attendant complexity (Sections 1.5 and 2.2 in [6]). Unfortunately, there's no shortcut here, so start simply and learn the rules as you go.
|
|
|
|
|
Noway2
2/24/2009 4:39 PM EST
I thought the article was ok, until I tried entering the first code listing. The code compiled and ran, but only gave me the "Hello, World!" output without any indication that the constructor or destructor was called. It also appears that the page has been encoded in such a fashion as IE7 won't allow me to cut and paste the listing or to change the font, etc. In effect, I have no way to verify it. Great. At this point, my opinion of the article plummetted. I expect better, thanks.
Sign in to Reply
feifeivictor
2/26/2009 6:52 AM EST
I didn't learn C++ on purpose.
i learnt something about VC++,lol
Sign in to Reply
ESD editorial staff: SRambo
2/27/2009 5:54 PM EST
To Noway2,
I added the actual code into this article (instead of just a picture of the author's code). Note that the code has some html characters in it.
--Susan Rambo
Managing Editor
Sign in to Reply
infoaccess
3/2/2009 10:28 PM EST
As a long-time embedded programmer I found the article seriously lacking in many aspects.
I use C++ & C in my current projects. However one of the main issues using C++ for embedded development is not because of the development tools or lack of interest from programmers, but the simple fact that C++ has to be restricted for real-time embedded applications and this makes many developers choose C over C++. Just to name a few of these restrictions: templates are not supported, exceptions are not supported (they introduce unpredictability in code execution time, which is a big no-no for real-time code), etc.
So these are the things if expanded on, would make this article worthwhile.
Sign in to Reply
DutchUncle
2/28/2011 9:09 AM EST
Why would templates be restricted in embedded applications? You wouldn't restrict macros in assembler, and C++ templates are more like assembler macros than C macros are (because C macros are simplistic text substitution while templates have semantic context).
I agree, it's the time-wise unpredictability of many of the advanced constructs that is dangerous. Dynamic allocation, for example, no matter *how* it's named and invoked. I would always rather declare a fixed pool of whatever records I need, with enough calculated to handle the situation, and manage the pool rather than allow dynamic memory management to decide when it needs to garbage-collect.
I remember the days when it was assumed that performance code had to be in assembler, and it was a hard sell to engineers that a compiler could optimize on the back end. I'd like to think I helped convince a few people on a project switching from Z80s to 68000 using Pascal; when you have a few extra registers and addressing modes to work with, you can generate cleverer things than most people will code by hand. Today the ARM instruction set and a good compiler will produce *much* better code.
Sign in to Reply
jscott27
9/3/2009 9:03 AM EDT
"C++ isn't a programming language; it's a worldwide research project running about in disguise." Based on this statement, I would infer that C++ is not appropriate for production products (only research) and especially not for safety critical projects. I would also infer from this that C is a much better choice because of it's stability.
Sign in to Reply
Denis.Lebel
2/28/2011 11:31 AM EST
I'm biased cause I'm a long time C programmer. However my few trial with C++ has not been positive. I like things clean and simple but the encapsulate and hide approach of C++ makes me uncomfortable about the robustness of the code. I know in the end C++ will prevail but being just a few years from retirement I'm not sure the jump is worth the effort.
Sign in to Reply
seeker2
3/4/2011 1:12 PM EST
We have been using C++ for real-time embedded projects with two excellent libraries - ACE and BOOST. If your RTOS/GPOS is supported by ACE (supported list is quite extensive), you can benefit a lot in terms of quality and convenience. I especially like ACE's OS abstraction feature which allows me to build same code base for multiple OS targets. I can create and debug in the comfort of my home by building the project for the Windows OS using the Visual Studio (non-realtime code, of course), and then simply re-target the build for the end-product's OS. This way, I am not bound to the hardware for debugging. I think one should be careful not to make catch but seriously flawed declarations such as "... it's a worldwide research project..". Put in the time and effort to be proficient at it; my bet is that those who do will not go back to C.
Sign in to Reply
KANAKA.VARANASI
3/11/2011 11:54 AM EST
Our company initially had C/C++ software for Embedded application on IBM OS/2 and Windows XPE. Now they are converting into a Java based application. In spite arguments about the advantages and disadvantages of using Java, the Java application is slower than C++. But I still incline towards C++ more. Thanks for the nice article.
Sign in to Reply