C to C++: 3 Reasons to Migrate

Jacob BeningoOctober 31, 202222 comments

I’ve recently written several blogs that have set the stage with a simple premise: The C programming language no longer provides embedded software developers the tools they need to develop embedded software throughout the full software stack. Now, don’t get me wrong, C is a powerhouse, with over 80% of developers still using it; however, as embedded systems have reached unprecedented levels of complexity, C might not be the right tool for the job.

In this post, I’m kicking off a series of blogs looking at how developers and development teams can transition from using C to using the more modern C++ programming language. To get us started, we will examine three reasons why teams should consider migrating to C++.

Reason to Migrate #1 – You can still use C

This article is available in PDF format for easy printing

The first reason to migrate is a strange one. Yes, the reason to migrate to C++ is that you can still use the C programming language! Why is this important? When we switch to a new programming language, in my experience, it takes developers upwards of 12 – 18 months to fully integrate and become proficient with the new language. During this time, developers still must launch a product and produce results.

With the teams I have been working with transitioning from C to C++, we still leverage C for low-level hardware accesses and areas of the code base where procedural programming makes a lot of sense. At the higher-level areas of the software, such as the application stack, we focus on writing object-oriented software that leverages what C++ is good at. During a crunch, if developers are more comfortable with C, they can knock out the code in C and later rewrite it in C++. Since C/C++ has similar syntax, it can be very efficient to rewrite later.

Figure 1 shows the idea of breaking up the application into C and C++ sections using a hardware dependent architecture (written in C) and a hardware independent architecture (written in C++).

Figure 1 – An embedded software architecture separated into hardware-dependent and independent architectures that interact through an abstraction layer. (Image Source: Embedded Software Design[1]).

Reasons to Migrate #2 – Attract New Talent to the Team

If you survey the programming languages taught at the university level, you’ll find languages like Java, C++, and Python are the top languages. However, you won’t find a C programming language course even within the embedded systems curriculum. With C not being taught at university, it demonstrates that higher academia is looking at more modern programming languages to solve the challenges of the contemporary age, not relying on an antiquated 50-year-old language.

The fact that C is not taught at the university level has other problems associated with it. For example, any new talent coming into the industry will not be proficient at using C. In fact, I’ve seen developers shy away from using C as much as possible. Given a choice, they would instead write Python test code than dig into C. If C is a requirement, you’ll find that you can find great entry-level and early career talent, but they will either shy away from your opportunities, or if they do bite, you must spend months training them to use C.

Migrating to C++ offers an opportunity for new talent to come into a project and be effective from day one. They’ll be able to leverage the object-oriented programming techniques they are familiar with and write some fantastic code much sooner.

Reason to Migrate #3 – Portability and Reuse and Critical

The modern embedded system is a complex beast. Countless teams are moving to microcontroller-based systems where the microcontroller has megabytes of flash space, hundreds of megahertz of processing power, and complex connectivity stacks that must be managed. Even simple edge devices like light switches need to connect to wireless routers, talk to back-end servers, manage the local real-time sensor processing, and even be aware of their environment for context processing[2].

Amongst all this complexity, companies don’t just offer a single product to the market anymore. Instead, they offer their customers several SKUs, product offshoots, and many options. As a result, developers are left with a complex, configurable code base to manage that requires portability for different hardware configurations and a need to reuse as much code as possible.

C is a procedural language. Yes, we can reuse code and fake many object-oriented tools, but it requires a fair amount of extra effort when C++ offers it out of the gate.


In this post, we’ve explored three reasons developers and teams might want to consider moving to C++ from C. We’ve only scratched the surface. There are a ton of reasons why developers and teams may want to move to C++ or some other language from C. Please don’t get me wrong, either. I love C. I’ve spent the last 25 years writing 95% of my projects in C; However, I see the growing need for using a more modern language. It doesn’t mean that we need to throw C away, but we need to start limiting it to the low-level hardware interactions it is good at and to smaller, less complex projects. We can then leverage a more modern language to manage our complex application needs.

In future posts, we will discuss what teams and developers need to do to help them smoothly transition to using C++, along with the technical details about using C++ in embedded systems.  

[1] Beningo, Jacob. Embedded Software Design. Apress, 2022

[2] Think about a light switch that turns the light on when you look at it and say “Turn the light on”.

[ - ]
Comment by MatthewEshlemanNovember 2, 2022

More and more, when I mention my preference for C++, I get asked:

What about Rust?

I still do not have an answer to that particular question.

[ - ]
Comment by beningjwNovember 2, 2022

Rust is an interesting potential language at the moment. Unfortunately, it does not currently have a standard like C/C++ and is evolving quite rapidly. So writing production code with it that needs to be maintained over the long term is potentially risky and costly. 

It's possible that risk could be mitigate by some of the problems it solves. Rust though is still an unknown, and it may require more upfront costs to train everyone. 

I like the language, but it really depends on the business case as to whether it fits or not. 

[ - ]
Comment by beningjwFebruary 25, 2023

When I am asked about Rust, I often respond that Rust is an interesting and exciting language, but there are several points to consider about it. 

1) It does not have a standard and is evolving rapidly. Code written today might not compile tomorrow, or worse, compile differently. 

2) There are not many embedded developers experienced in Rust, which means you either pay top dollar for talent, or spend a lot of money and time to train developers. 

3) Many of the Rust benefits in the standard library are disabled for embedded builds. 

4) Rust is not an easy language to learn. The learning curve could introduce additional risk into the project. 

One day Rust might become a viable alternative, but C++ is a much more natural language to adopt especially if a team is moving away from C. 

[ - ]
Comment by cmarsalcNovember 2, 2022

Hi Jacob!

I am all in for using a more type safe language with support for inheritance and templates and with no performance impact, specially if when developing reusable that have to fit certain framework or developing this framework itself. I mean using a reduced set of C++ features, basically inheritance and templates with static memory.

Right night I am facing several challenges or questions I don't really know hot solve. Maybe you can point me (or get Dan Saks to do it :) to some solutions:

  • Initialization order of global memory objects is undefined. This can be solved with singletons but lead to dynamic memory which I would prefer to skip.
  • Lack of free static analysis tools. Right now with cppcheck you can check MISRA C 2012. For C++ we have MISRA C++ which is way obsolete. We also have autosar and MISRA and autosar have confirmed to publish a joint standard but date is still not on the calendar. There is no free static analysis tool for C++ autosar usage guideline.
  • How does the decision to "jump" to C++ stands of in front of alternatives such Rust. I think C++ has a fairly smoother transition from C as they can co-exist pretty easily but I have not really done an deep comparison of alternatives.


[ - ]
Comment by beningjwNovember 2, 2022

I can answer a few of these for you:

  • Lack of free static analysis tools. Right now with cppcheck you can check MISRA C 2012. For C++ we have MISRA C++ which is way obsolete. We also have autosar and MISRA and autosar have confirmed to publish a joint standard but date is still not on the calendar. There is no free static analysis tool for C++ autosar usage guideline.

I would not use MISRA C++ today. It's too outdated. Using AUTOSAR and/or the Google C++ standard I think are worth looking at. 

As far as free static analysis goes, it would be great if someone would create one! I suspect because they are more likely to be used by professionals, and the work involved in creating a good one that covers the standards, these will continue to be "pay for".  

I use a relatively low-cost tool called Understand from SciTools to perform basic C++ static analysis. Unfortunately, I'm not aware of anything that is free.

  • How does the decision to "jump" to C++ stands of in front of alternatives such Rust. I think C++ has a fairly smoother transition from C as they can co-exist pretty easily but I have not really done an deep comparison of alternatives.

The companies that I work with don't have the risk tolerance to switch to Rust right now. It's still too new and has too many unknowns. C++ they are more comfortable with. 

Both languages can use existing C code, but syntax wise C++ will be much easier for C programmers to transition to.

[ - ]
Comment by JonnyvbNovember 3, 2022

Is clang-tidy not a free static analyser?

[ - ]
Comment by beningjwFebruary 25, 2023

it is . . .

[ - ]
Comment by DKWatsonNovember 3, 2022

I'm all for using whichever tool best fits the task. If the only tool in your kit is a hammer, you tend to build everything with nails. In the world of embedded computing, which perhaps requires a more detailed definition, the reasons one would choose C++ over C are the exact reasons one should shy away from C++. With memory constrained devices, said memory needs to be managed very carefully. Any use of dynamic memory is to be avoided like the plague, one reason to exercise extreme caution when choosing C++. It may come down simply to how much memory you have on board to play with. I work primarily with sub-dollar 8-bit processors where Mbytes of memory is simply not an option and must at times devolve to writing assembly due to space constraints. Perhaps a separate discussion is warranted as to which tool is best suited for the task at hand. If you look at market numbers for 8-bit processors that are growing at a rate of just under 5% annually, ignoring C in mainstream education may be resigning the future to offshore outsourcing. Dare I suggest looking into the demand for experienced COBOL programmers?

[ - ]
Comment by beningjwNovember 3, 2022

Thanks for the comment. I definitely agree on many of your points. A subset of C++ though can be very powerful for developers without running into too much risk or other issues. 

[ - ]
Comment by ilya1725November 17, 2022

Great article. But it is just the beginning. There are many more reasons to switch than Jakob outlined. In my experience, C++ presents a significant improvement for Embedded SW development (remember that next time you are chasing down a resource leak bug). 

I find it bemusing when people state that C++ requires more resources. My first C++ project 20 years ago was happily running on a desktop PC with orders of magnitude less memory than some of today's IoT systems.

There are many reasons teams are reluctant to switch to C++. But, in my experience, inertia is the major. It is practically impossible to switch a currently shipping C project to C++. A new one - there is a chance, a current one - very little. The suppliers are often not helpful. The tools, IDEs especially, are setup "out of box" to use C. One has to either complain or outright hack the compiler and linker to use C++.

[ - ]
Comment by beningjwNovember 17, 2022

Great observations! Thanks for sharing your experiences!

[ - ]
Comment by juanferfrancoNovember 2, 2022

What about moving from C to Rust? For example Espressif is investing a lot in Rust. What do you thing?

[ - ]
Comment by beningjwNovember 2, 2022

I think it will be interesting. I don't think we'll see it widely adopted though until you see STM, Microchip, NXP, etc provide their code bases in Rust. 

A transition will take at least a decade in the industry and it will be in pockets where it makes the most sense. 

I'll likely cover some Rust topics here and there as well in between C to C++

[ - ]
Comment by conelecNovember 2, 2022

I can't see C++ being of any benefit in mostly small 8/16 bit processors where resources are tight. What kind of embedded controllers are you proposing that would benefit from C++ ? As far as I am aware companies like Microchip are only now releasing compilers that can handle C++ and then only for the 32 bit CPU's. I may be wrong but C++ on embedded systems seems like a whole new level of crazy. They stopped teaching FORTRAN at universities and now programmers with this knowledge are earning big bucks. Just because they stop teaching something doesn't make it obsolete by default. If something works, why reinvent the wheel.

[ - ]
Comment by DNadlerNovember 4, 2022

C++ can provide enormous benefit on smaller processors; I've been using C++ on a 16-bit x86 embedded product for >25 years! Microchip is horribly behind the curve, but we shipped a product using C++ on PIC32MX more than a dozen years ago (using Code Sourcery compiler)! All major manufacturers support C++ now (we've used it on assorted ARM Cortex M devices for years).

Even on small devices, C++ really helps with abstraction. Templates can make it much easier to write high-performance and more compact (both source and generated) code. None of this requires using heap memory or exceptions or more heavy-weight C++ libraries.

Don't diss C++ just because you're not familiar with it! Spend some time to learn a bit about it and you'll be surprised.

[ - ]
Comment by beningjwNovember 5, 2022

Well said! Thanks for your adding your insights to the discussion!

[ - ]
Comment by beningjwNovember 3, 2022

In very resource constrained systems, that are small from a code stand point, there might not be much benefit to C++ over C. If the application is simple and procedural programming fits well then certainly use C. 

I've seen many applications though where C++ is probably a better choice. Yes, 32-bit MCU's are a good place, but some 8-bit parts can be quite complex and resource heavy as well. 

Thanks for the comment / question. 

[ - ]
Comment by beningjwFebruary 25, 2023

C++ for embedded systems has been around for a very long time. It works great in 8 and 16-bit environments. You have to look no further than Arduino to see the power of C++ in resource constrained devices. 

C++ is an evolution of C to allow OOP and more modern language features to manage memory, reuse, portability, and much more. 

[ - ]
Comment by alfkatzJanuary 12, 2023

All true for relatively large processor based systems and where real-time real-fast is not a requirement.

I prefer to think of C++ and C as tools for different jobs, along with languages such as C# and even Python that allow a higher level of abstraction.  C is great on resource and $ constrained systems such as low cost peripherals and at the bottom level of operating systems where utmost speed is required (sometimes you even need assembler at those levels).  For systems where development time is the chief constraint and the cost of hardware is not important (a few extra gig of RAM or a few more GHz costs less than a man year of dev time), I'd go to a higher level language than C++.

However, there's a lot of room in between where C++ is the ideal choice.

Like someone else said, when all you have is a hammer, everything looks like a nail

[ - ]
Comment by beningjwJanuary 13, 2023

Thanks for the comment. 

I disagree with you on C being the choice on constrained systems. C++ can provide just as efficient code on constrained systems as on larger systems. We'll be exploring some of these misconceptions in the following posts. 

The choice between using C or C++ really comes down to if the developers are familiar enough with the language to choose the right tools from the language and whether the OOP paradigm benefits their longer term goals. 

[ - ]
Comment by KKratzerFebruary 20, 2023

Jacob, I recall my professor taught the class to always write a file for testing the function in C++. With the thought of increasing the reasons to switch to C++, does C++ lend itself more to test driven development than C? Is so would you please expand on the answer?

[ - ]
Comment by beningjwFebruary 25, 2023

Oh definitely. I typically use CPPUTest for my test harness when working with C. The test harness is a C++ harness. So when I use C++ and TDD, I still use the same tools I did before, I just write C++ code. 

To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.

Please login (on the right) if you already have an account on this platform.

Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers: