Back when I was an engineering student and a budding young engineer, it wasn’t unusual to open (yes physically open) the latest edition of embedded systems magazine and find articles that were contributing to the raging war between C and C++. Each side would present their cases as to why one language was better than the other. The C developers usually argued that C++ produced bloated and inefficient code while the C++ developers would argue that C++ could do everything C could, only better. Over the last several years, the rhetoric seems to have died away, leaving me to wonder “Is the war between C and C++ over?” and if so “Who won?”.
In order to try and get an answer, I thought the first place to look would be to see if there has been any change in the general popularity between using C and C++. One of my favorite sources for this type of comparison is the TIOBE Index. The TIOBE Index has been tracking the popularity of programming languages in general since around the year 2000, providing 20+ years of popularity data. If you look at the TIOBE Index from February 2020, shown below, you can see that except for a small period between 2003 and 2005, the popularity between C and C++ really has changed that much. In fact, if anything it looks like C++ has actually lost momentum when compared to C!
This might seem to suggest that C has won, but how do things look specifically within the embedded systems industry? If we go back and look at the embedded.com embedded industry surveys and examine the programming language usage data for C and C++, we find the following:
In all honesty, the above comparison to me generally looks pretty flat. Sure, you could say that the general trend since 2005 has been that C is trending up and C++ down, but the if I were to calculate the standard deviation in the measurements that trend is just in the noise. We could also say in the last five years C++ has been trending up and C has been trending down, but again the same issue.
So how does C and C++ seem to compare within industry? As I look out at general trends as it pertains to using C and C++, I feel that there are several worth noting. First, companies that sell microcontrollers and microprocessors generally are still providing their clients with software stacks that are written in C. I don’t see ST Microelectronics, Cypress, NXP, Renesas, Silicon Labs, and so on providing C++ software stacks to engineers, they provide all their code and examples in C. Second, when I start to look at commercial and open source software packages for RTOS’s, bootloaders, file systems, etc, the majority all seem to be written in C.
This quick look through industry might lead me to believe that C has won, but the answer unfortunately is not that simple. For example, look at popular software stacks such as Arduino and mbed. These software frameworks are completely written in C++ and are gaining more and more popularity with time. In fact, I’m seeing a trend where mbed is being leveraged more and more by the chip manufacturers and not just by hobbyists or electrical engineers looking to get something done quickly.
While the verbal and written war between C and C++ seems to have died down, C++ might actually be starting to gain some ground in embedded systems. There are several reasons why I believe that C++ is slowly growing in popularity which include:
- Continued improvements in the C++ standards
- Continued improvements in C++ compiler technology
- How easily C can be wrapped and used within C++ applications
- Access to classes, templates and other object-oriented constructs that are not included in C
- Availability of useful C++ resources such as:
- Real-Time C++ by Chris Kormanyos
- Effective Modern C++ by Scott Meyers
C++ has continued to evolve over the past decade, especially with major changes that occurred in C++ 11 and C++ 14. While C has been improved, for the most part the improvements have not been supported well and most teams working with C still use C99 as their tried and true compiler. I think a lot of the old arguments for why C++ doesn’t work in embedded just don’t apply anymore. These arguments often revolved around how C++ bloated code, was inefficient and just couldn’t access hardware as well as C. These just aren’t true anymore and may not have even been valid back then.
When C++ is used, care certainly does need to be taken. Developers can’t use every standard library feature, or they will potentially get inefficient, bloated code. They also need to be careful that any dynamic memory allocations are done during start-up so that they don’t run into memory issues like heap fragmentation. These are issues that even C developers need to be careful about, so they don’t preclude the use of C++.
I don’t think the war between C and C++ is over, but I do think that it has moved from a verbal and written battle to a battle of market share. At the end of the day, C and C++ will continue to be used in embedded systems for decades to come, locked in an eternal battle for dominance. With the growing capabilities of compilers and microcontrollers, along with a careful use of C++ features, there’s no reason that C++ should be immediately ruled out or excluded from being used in embedded development.
So the evidence is with slight trend up for C and down for C++, the C usage is at least twice of that of C++ but conclusion is that C++ is winning … interesting, as Brits would say …
The problem with C++ is still the same. The standard body is obsessed with speed and matching any sexy features some other programming language just introduced. Sure you can embed C++ with “some care” but then again why waste time for additional “care” and just use C?
C++ helps in usual places, foremost where there is rich GUI. This nowadays means that the platform is Cortex-A or x86 with preemptive OS in between and something like Qt or StoryBoard as the main framework. Here C++ might be the better choice.
As for embed and Arduino: these are great for quick jobs/experiments/auxiliaries on MCUs where I really do not want to dig under the (software) hood (usually I need to control some experimental hardware, quick and dirty). In such situation if I need to start to care if there is C or C++ underneath then I consider the solution failing.
As an embedded programmer for the Allwinner H2+/H3 SoC, I am implementing all protocols in Modern C++. There is no overhead in programming C++ versus C.
My preference is using the best bits of C++ (classes) and the rest C like.
Same here. I have written the low-level hardware interface in C. But all other is written in C++.
Jacob, When looking to see which language will one day exceed C, would it be fair to forecast micro python, as the heir of C++ could possibly one day exceed C for embedded applications? Thus C++ with albeit through micro python.
I would be in that camp yes. I don’t think a single language will ever be the “one language to rule them all” but with how popular Python is, it will undoubtedly become very dominant in the future.
Jacob, When looking to see which language will one day exceed C, would it be fair to forecast micro python, as the heir of C++ could possibly one day exceed C for embedded applications? Thus C++ wins albeit through micro python.
In time possibly, but it’s interesting to keep in mind that Micropython under the hood is still all C.
Python is a ‘slow’ interpreter language. That is not comparable with C++ (or C) where you can have zero-overhead compilation. And then very fast assembler code.
Definitely agree! Although in certain applications and given how powerful and cheap microcontrollers have become, many applications can deal with the ‘slow’-ness of Python without any issues.
When looking at the first graph, I was actually thinking that the recent raise in python that looks tightly correlated with the recent raise in C. Is not an coincidence.
Maybe not. Just recently I took part in a discussion on a project which will require serious computational capacity. The proposed and realized architecture seems to involve Python-based staff on the top levels (UI, CLI, the compute pipeline management code and like). But the low-level engines including the per-used Python libraries are written in C (if not also in FORTRAN!).
For a wide class of numerical or like problems there is no real incentive to use OOP … and it is not about the performance, it’s just that OOP adds stuff which is really irrelevant to the main problem …
… sorry about typos: “staff” should be “stuff”
One driver is the apparent fact that C is not taught in many, if any, colleges. They use either C++ or some other OO language to base their CS curriculum on. This means that as old engineers like myself fall out of the work force, and they are replaced by younger employees, they will have a preference and bias towards C++. That is what I see as the major driver of the shift to C++.
Good article, I use both C and C++ for all of my software engineering. The type of job determines the platform and language.
If the platform is a PC or Unix/Linux box which usually means the application is GUI based I want the power, and flexibility of C++. I’m usually developing custom CAD, CAE applications which are quite complex and an object oriented language is helpful. And there is lots of compute power, electrical power, RAM, and hard-disk space.
For real-time embedded intelligent instruments that are battery powered, and usually running on 8, 16, or 32 bit microcontrollers, I use C because it’s “Lean and Mean”. You want the processor sleeping as much as possible with a smaller memory footprint.
This was very good, and I have to admit, I’ve been of the impression the war of C vs. C++ had basically died as well. Perhaps that sense also comes from a lack of magazines, as part of me years for the days when we had Embedded Systems Design and many others I used to be able to pick up copies of at ESC (at least, any I didn’t already subscribe to).
I think the point of how C++ has changed a lot recently while C hasn’t is a good one. I sense that the C++ committees are very active, plus they’re committed to getting something out every three years; I get no such sense with the C standard committees. I was recently at a company that wants to become much more of a C++ place than C with their embedded software; currently I’m at a place where there is a big mix and I’ve dealt with both (currently more in C as I work at the RTOS level).
One interesting thing I have noticed is less use of C++ as a superset of C – it’s much more common for me to see C++ code being completely object-oriented.
“For example, look at popular software stacks such as Arduino and mbed. These software frameworks are completely written in C++ …..”
And I spend time every month ‘Flattening the classes’ out of Arduino C++ code so I can use it in my ‘C’ Embedded projects…. Ha, ha, ha, ha…
1. More complex language = more bugs in compiler.
2. More changes in language = more changes in compiler = introduce new bugs in compiler = more bugs in compiler.
3. Debugging templates in target = awesome.. not.
4. Debugging bugs in compiler for a complex language = awesome.. not.
While C++ certainly is a language that you can use to shoot your feet in so many inventive and new ways, I don’t think it’s suitable in general into places where you want to keep the amount of complexity down. The effort it takes to use C++ in a “simple” manner just doesn’t seem worth it to me, someone will manage to use it in a complex way anyway when you’re not looking.
(I’m not claiming C is safe, far from it. It is simpler though)
Perhaps Rust will do better eventually.
Thanks for your comments!
Most of your arguments against C++ have nothing to do with the language itself but more about concern with compiler bugs. While these certainly will exist and are a pain to deal with, the chances the average developer will encounter them are going to be pretty slim, unless they are trying to leverage some poorly supported open source compiler or something. A bug in an IAR or KEIL compiler for general use features is probably pretty low.
I also think that the prevalence of frameworks like Arduino and mbed have shown that using C++ is easy for everyone, including people who know nothing about programming languages.
This is why I wrote the article though, to get great feedback and comments like we are seeing here to see where the state of C versus C++ is at.
Sorry for not being clear. C++ is much more complex language and I tend to avoid increasing complexity in embedded context. It is not a matter of “skill”. take any group / team of people working on embedded and see what trainwreck comes out of disparate skill levels with C vs C++.
If you’re working alone on something, language choice doesn’t matter. Use what you’re comfortable with and will get you to the goal.
Well you can write complex, bloated and unmaintainable code in any language, you can’t blame the language for that. That is like saying that French is better for expressing love, than english, if you are fluent in French and new to English that is maybe true, but if are fluent in English and new to French the opposite is most likely true.
It has way more to do with the skills of the developer than the language used.
I know that my example don’t consider the big difference between interpreted language to compiled languages when we talk computer language, but I hope you get the picture.
I agree to certain extent: either you have enough discipline or not. However a bad driver is likely to do more damage if given a Ferrari instead of a Chevy … make Ferrari Tesla and still this does not seem to matter …
“The language itself” phrase needs more context. Are we talking about the syntax and semantics of the language or the whole ecosystem? From my point of view (safety-driven design, most of the time: deterministic e.g.: Real-Time), one of the problems is the behavior and attitude of the steering bodies to cram in C++ almost anything new which comes along while disregarding special needs of the embedded systems. The embedded system being dismissed because soon everything will be on 32 or 64 bits with lots of memory, right? NO. Physics do not care for the human spin. Small always will be cheaper including cheaper on power and while the geometry may not shrink forever the silicon will continue get cheaper for some time causing small micros to find new fields of use. So C will stay. I am not dismissing C++ but every tool is suitable in certain situations and none is suitable everywhere/everytime.
I’ve recently started using TouchGFX. It’s very capable, both in terms of code generation and extensibility in C++. I’d be interested if anyone else has experience with it, as the only real source of information is ST’s own documentation and forums.
When C compilers became available for MCUs, it was a great replacement for assembly language. The compilers have improved so much that their codes are efficient and can do almost all the low level stuff, including setting up vector tables and writing ISRs. However, code-reuse in C often requires one to pass pointers to structures to functions so that the function can use that context to do the necessary. The concept of pointers is hard to grasp for many.
My experience changed completely when I started to use the Arduino platform. (mbed is another good example.) I was amazed to see the availability and use of C++ in a humble 8-bit MCU making programming so much simpler. The use of class to encapsulate data and methods, overloading and hiding internal implementations, make creation of re-usable codes so much easier. The dot notation is also very intuitive. I believe C++ is a key factor for the success of Arduino. The quality of codes in Arduino has also improved very significantly over the years. Porting to different MCUs that support Arduino is easy if the basic APIs implementation is done well.
I believe for MCUs, we only need to use basic subset of C++ to significantly improve productivity, similar to those features used in standard and typical Arduino libraries. Don’t use the complex features. Given a choice I would not wish to go back to C anymore.
It reminds me of the jump in productivity going from C++ to C# in the non-embedded world.
If ’embedded’ means microprocessor-based (external RAM via MMU, like Cortex-A or similar class) then C# actually makes for me more attractive choice than C++. Of course if a more higher-level encapsulating platform/framework based on C++ is used (like Aduino, mbed) then well, when in Rome …
Yea “embedded” to mean basically means microcontroller. Once you get to Cortex-A I feel like these are more general computing platforms than true embedded systems. That is completely debatable though and maybe is more old school now-a-days.