Poor reasons for rejecting C++
My colleague, Michael Barr, wrote an interesting piece earlier this month, entitled "Real men program in C."1 I won't try to summarize it--you can read it yourself. The article provoked numerous comments from readers citing reasons to prefer C over C++. I disagree with several of those comments, and I'd like to say a little in reply to each.
One reader wrote, "Just for the fun of it you might as well want to have a look at what Linus Torvalds thinks about C and C++," followed by the URL to the remark (which I've omitted intentionally).
I suppose reading what Torvalds wrote would be fun if you like reading rants. It wasn't fun for me. It's provocative but not well grounded, as explained by my friend and colleague Steve Dewhurst.2 Torvalds has made positive contributions to the computing industry, but this wasn't one of them.
Another reader wrote, "I've studied C++ but never used it professionally and, the more I study it, the less I think it appropriate for embedded use. It's not just that it is expensive in terms of resources; it encourages you to do too many risky things. It's bad enough that you can do things like dynamic allocation and recursion in C but, in C++, the language will do it without your ever realizing it, unless you know what it's doing behind the scenes..."
I have used C++ for prototyping embedded systems and consulted for others who have developed production systems in C++. The more I use it and see it used, the more convinced I am that it's preferable to C, when available.
Rather than encourage risky behavior, many of C++'s core features--such as classes, access control, constructors, destructors, references and overloading--work hand-in-hand with stricter type checking to help rein in the riskiest parts of C. While I agree that typical C++ code tends to be a bit larger and slower than comparable C, the added expense is rarely prohibitive (on the order of 10-15%). I've had little problem tuning time-critical code, such as interrupt handlers, to be as or more efficient than it would be in C.
I know of no place where the C++ language performs dynamic allocation or recursion behind the scenes. Indeed, your code might call a function that uses dynamic allocation or recursion, but this is no more a problem in C++ than in C. In fact, C++ supports simple compile- and link-time techniques you can use to explicitly prevent using dynamic allocation, which I'll cover in an upcoming column.
Yet another reader wrote, "The only part of object orientation that is a must-have in embedded systems is private encapsulation. C supports this nicely enough with static variables declared at file scope."
While I agree with the basic sentiment of the first sentence, I wouldn't word it so strongly. I would say that the single most useful feature of C++ that's absent from C is classes with private access control. I would not call it a "must-have" feature simply because programmers do write viable embedded systems in C--without classes. However, you can write better embedded systems with classes. I wouldn't want to code without them.