C++ on Small-Footprint Microcontrollers

Question

It seems to me people consistently shy away from, or rather vehemently oppose the use of, C++ on microcontrollers, but I can't for the life of me figure out why. If you stay away from large C++ libraries (e.g. STL) and you don't try to use complicated features like RTTI or exception handling, is there really any noticeable difference between C vs C++? Does virtual inheritance have a huge impact on complexity or footprint? I would think it'd be a little extra memory, but most of the complexity would be handled by the compiler, but then again I don't know a lot about that dark magic. I just don't understand why people are pretty adamant about using C, except maybe for the few architectures for which there aren't C++ compilers (if there are any). It seems the benefits of modularization and templates would be a no-brainer, even if you couldn't use your cin or cout.

I ask because I'm doing some research for some hobby projects I'd like to work on. Ideally, I'd like to work with C++ strictly for the capability to nicely modularize things, vs. C's "SomeClass_SomeMethod( struct object* this ... )" approach to "object orientedness". (I'd much prefer object Pascal for these projects, but alas support for that language isn't exactly stellar...) I would rather avoid moving to a much more capable microprocessor because A. for the projects I'm doing, I don't need tons of resources.. I'm not planning on writing 60 state Kalman filters or encoding 1080p video B. (the real kicker) I'd like to use processors available in DIP and QFP packages. I'd like the ability to prototype without soldering or baking anything in my toaster oven.

Any thoughts?

Answer 1

In C++ you essentially only pay for what you use over and above what would otherwise be C compilable code, and some of the extras are cost free.

The biggest issue with some C++ compilers for small targets is the completeness of available C++ implementations or the availability of a C++ compiler at all.

EETimes/Embedded.com has run a number of articles on the subject over the years:

• Better even at the lowest levels - Dan Saks
• Embedded C++ Yields Faster Smaller Code - John Carbone
• Why C++ is a viable alternative to C in embedded systems design - Fergus Bolger
• Poor reasons for rejecting C++ - Dan Saks
• Using C++ Efficiently in Embedded Applications - Mentor Graphics/Cesar A. Quiroz
• The Inefficiency of C++ , Fact or Fiction? - IAR Systems/Anders Lundgren

The point most of these articles make is that you should not necessarily use all of C++ in an embedded system and they measure or explain the cost in terms of memory, speed, and determinism of various features. What parts you use will depend on the nature of your application (whether it has real-time constraints for example), and the available resources and performance of your target platform.

Answer 2

The C++ committee wrote a (free) technical report on this subject.

Answer 3

Of course it varies a lot.

I wouldn't use virtual inheritance on a "small" MCU. I wouldn't even use a heap at all.

The features of C++ that seem most attractive in that space are namespaces (to share software components between programs for networked MCUs), templates (e.g., to parameterize protocols over I/O ports), and general semantic improvements like static_cast and less coarse integral promotion.

But, at least in my brief foray into professional embedded, a suitable C++ compiler simply didn't exist, and the crappy one that was available cost thousands a year.

GCC is the most capable, widely-available C++ compiler available for embedded platforms. However, its platform support is very uneven. If you have unlimited resources, EDG advertises that they will bring support superior to Comeau to "your" embedded platform.