More than a decade ago there was a constant debate and anticipation as to when C++ would finally eclipse C and become the dominant embedded systems programming language. To this day, C still remains the dominant language and doesn’t seem to being anywhere anytime soon. Given the advances in microcontroller hardware and more importantly, the toolchains and the optimizations that are now available with them, it may be time to start transitioning from using C to using C++. Here are several reasons why developers should start considering using C++ in their embedded systems.
Reason #1 – Use modern object oriented programming techniques
The C programming language is a procedural language that was invented almost 50 years ago. It’s a great language but it lacks everything that a modern programming language has such as
C developers can sometimes emulate these foundational object oriented features but it’s always forced and requires more effort. A modern language naturally uses these techniques and if used properly can improve code readability, reuse and portability. In today’s complex systems, it sure would be nice to use classes and objects that can then be reused from one application to the next.
Reason #2 – Compiler and toolchain support for microcontrollers
Over the last few years, the support for C++ in compilers and toolchains in the microcontroller space has been a heavy focus for tool providers. Examine a few commercial and open source compilers and you’ll quickly discover that the latest C++ standard, C++14, is fully supported by the compiler. Examine those compilers for the latest C standard, C11, and you’ll be lucky to find a compiler that supports even a few of the latest features.
Beyond just compiler support, microcontroller manufacturers are starting to include hooks in their own tools to be able to easily develop C++ applications. There seems to be a quiet storm brewing where C++ could quickly become the dominate language in the embedded space.
Reason #3 – Active standards committee
The C++ standard is updated far more frequently than the C standard. The C standard was updated in 1999 and 2011. The C++ standard has been updated four times already with another version expected out in 2017 and every three from then. The updates aren’t necessarily just improving C++ but updating features and adding new features to stay current with the changes that are happening in industry. Despite all the issues, ambiguities and known issues with C, changes, updates and clarifications come at a snail’s pace if at all.
Reason #4 – Performance and code size
The greatest sticking point in the old debates between whether C or C++ should be used in an embedded system came down to performance and code size. The complaint was always that C++ code was larger and performed worse than C code. In today’s development environment, modern compilers and their optimizers are very good. Once again, a developer might need to experiment a little or limit their C++ language use to a subset that can guarantee performance but let’s be honest, we have to do the same thing with C anyways!
Reason #5 – Object oriented programming is taught everywhere
Everywhere, object oriented programming techniques are taught. University students learn either Java or C++ in their computer science classes. Software design more naturally adheres to object oriented thinking rather than procedural processes. New engineers are more likely to pick up and become productive faster using C++ than C because it naturally fits into what they have been taught during their four or five years in college. C will seem an old language that they have no way to relate to and that they will need to learn and we all know that C is a very quirky language. Those quirks take years to learn and master.
The C programming language isn’t going anywhere anytime soon; However, the tools available to developers to start using C++ and beginning the transition are available. C++ offers developers an opportunity to start using object oriented methodologies while at the same time, if necessary, continue to use legacy C code. There are many reasons to start using C++, and plenty to continue using C, but don’t be surprised in the next few years when more and more example code starts showing up in C++.
C++ is a quirky language too for exactly the same reasons that C is– it’s powerful and let’s you have serious control of things.
The biggest problem with C++ is hiding things that shouldn’t be hidden. Embedded programming requires you to know where every byte is all the time. You can certainly do that in C++ but schools aren’t teaching programming discipline (object coding is all well and good but it tends to offer a lot of bloat because, well, bloat is a whole lot easier to code and they are implicitly being taught resources are infinite, so why not take the easy path).
Therefore the modern school educated programmer still has a steep learning curve when it comes to embedded coding, C++ or C.
There may be many reasons to use C++ or even not C++ but something else (Lua, Rust, ADA, etc…). However there may be also reasons NOT to use C++. The foremost one is to use tools that fit the job. There are situations where C++ makes more sense than C: GUI required, required coverage of more than one set of hardware (abstract driver framework with the derived classes handling the device differences), the desired 3rd software is already in C++ and many more.
As for the above Reasons, they can be argued the other ways too:
Reason #1 – not every system needs Inheritance or Polymorphism, Encapsulation is easily achieved in C in many proven design patterns.
Reason #2 – there are many processors still without C++ support or without good enough C++ support (and there probably always will be …)
Reason #3 – the fact that C++ is updated so frequently maybe is not such a good idea, C is simply more stable because of that. Historically the C++ standard committee was NOT very receptive to the needs of embedded systems developers, the C++ folks being obsessed with speed and power of features. This may start changing because of the popularity of the mobile platforms, however I am afraid for them “embedded” is a smartphone or a tablet running CPU with MMU.
Reason #4 – This is no-reason. In many embedded applications the stability and predictability of the code execution is more important than speed or even (sometimes) the size. Here C beats C++ by its nature.
Reason #5 – OOP is taught everywhere. Good. Not so good that it is done with C++ though, IMHO. C is quirky? The practical C++ is not?! Let’s start with the boilerplate code for a good class design which usually is described in books over at least 6 pages or more, often with a whole chapter dedicated to it! Worse: because C is not taught frequently , there is an avalanche of resumes pouring into the trash bins of recruiters. Very often C is not taught because C++ is, on the mistaken and very dangerous premise than one know C by default if it knows C++.
Conclusions – It is correct that C is not going anywhere any time soon. However IMHO it is not going anywhere for a really looong time. As long as there is no drastic change in the way the processor are designed and made the 8-bit processors will exist and so C. If such drastic change in the underlying architecture happens it is also quite likely that C++ may not apply. The premise that C++ can replace C is relying on the assumption that C++ is a super-set of C, as I already said this is mistaken and dangerous assumption.
C++ is a bloated language, there is a lot of bollocks like auto variables and shared pointers. It hides memory management. It is not suitable for MCUs with limited resources and where low level programming is needed.
Thanks for your opinion. I will agree that developers need to be very careful how they use C++ and in which microcontroller environments they decide to use it in. There certainly are features that are less than optimal but there is a core set of C++ features that can be used that can be helpful to developers. The danger becomes when the subset is expanded or a developer does pay attention to what they are writing. Thanks again for the comment!
Auto variables are great for lambda functions, and some templated types. Otherwise I prefer to be explicit.
There still seems to be a lot of misconception about C++. You can think of C++ as a superset of C and can even just write C code and have better quality code using C++ compiler as the C++ compiler comes with a number of benefits without adding any memory or performance overhead.
C++ is an advanced version of C.