Blogs

C to C++: 3 Reasons to Migrate

Jacob BeningoOctober 31, 202215 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.

Conclusions

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 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.

Regards!

[ - ]
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 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 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!

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: