C to C++: 3 Reasons to Migrate

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.

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. 

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. 

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!

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.

Is clang-tidy not a free static analyser?

it is . . .

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?

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. 

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

Great observations! Thanks for sharing your experiences!

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

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

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.

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.

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

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. 

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. 

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

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. 

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?

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.