Is There Any Reason to Use C Instead of C++ for Embedded Development

Is there any reason to use C instead of C++ for embedded development?

Two reasons for using C over C++:

1. For a lot of embedded processors, either there is no C++ compiler, or you have to pay extra for it.
2. My experience is that a signficant proportion of embedded software engineers have little or no experience of C++ -- either because of (1), or because it tends not to be taught on electronic engineeering degrees -- and so it would be better to stick with what they know.

Also, the original question, and a number of comments, mention the 4 Kb of RAM. For a typical embedded processor, the amount of RAM is (mostly) unrelated to the code size, as the code is stored, and run from, flash.

Certainly, the amount of code storage space is something to bear in mind, but as new, more capacious, processors appear on the market, it's less of an issue than it used to be for all but the most cost-sensitive projects.

On the use of a subset of C++ for use with embedded systems: there is now a MISRA C++ standard, which may be worth a look.

EDIT: See also this question, which led to a debate about C vs C++ for embedded systems.

C++ compiled C code vs Pure C in embedded programming?

Any comparison only makes sense when you are looking at particular compilers. Some leading compilers use the exact same back end for both C++ and C, and library choice (that impacts disk footprint, memory footprint, startup time and almost everything else) is determined quite freely and in a much more granular way than just C vs. C++, supposing you really care.

So in that case the answer would be, no, the file extension does not matter. But calling a C program C is very good to make your decision to limit the product to C to be understood within your team.

Note that a lot of the argument against C++ in embedded development comes from an era a decade or more ago when C++ compilers struggled to implement the language correctly, and sometimes at the expense of predictable performance or runtime size. All today's practical language wars for embedded devepment that are fought close to me tend to be between C++ and C# and C is rarely even remembered.

Why would anybody use C over C++?

Joel's answer is good for reasons you might have to use C, though there are a few others:

• You must meet industry guidelines, which are easier to prove and test for in C
• You have tools to work with C, but not C++ (think not just about the compiler, but all the support tools, coverage, analysis, etc)
• Your target developers are C gurus
• You're writing drivers, kernels, or other low-level code
• You know the C++ compiler isn't good at optimizing the kind of code you need to write
• Your app not only doesn't lend itself to be object-oriented but would be harder to write in that form

In some cases, though, you might want to use C rather than C++:

• You want the performance of assembler without the trouble of coding in assembler (C++ is, in theory, capable of 'perfect' performance, but the compilers aren't as good at seeing optimizations a good C programmer will see)

• The software you're writing is trivial, or nearly so - whip out the tiny C compiler, write a few lines of code, compile and you're all set - no need to open a huge editor with helpers, no need to write practically empty and useless classes, deal with namespaces, etc. You can do nearly the same thing with a C++ compiler and simply use the C subset, but the C++ compiler is slower, even for tiny programs.

• You need extreme performance or small code size and know the C++ compiler will actually make it harder to accomplish due to the size and performance of the libraries.

You contend that you could just use the C subset and compile with a C++ compiler, but you'll find that if you do that you'll get slightly different results depending on the compiler.

Regardless, if you're doing that, you're using C. Is your question really "Why don't C programmers use C++ compilers?" If it is, then you either don't understand the language differences, or you don't understand the compiler theory.

We have to use C for performance reasons

"Nothing but C is fast [enough]" is an early optimisation and wrong for all the reasons that early optimisations are wrong. If your system has enough complexity that something other than C is desirable, then there will be parts of the system that must be "fast enough" and parts with lighter constraints. If writing your code, for example, in Python will get the project finished faster, with fewer bugs, then you can follow up with some C or assembly code to speed up the time-critical parts.

Even if it turns out that the entire code must be written in C or assembly to meet the performance requirements, prototyping in a language like Python can have real benefits. You can take your working Python prototype and gradually replace parts with C code until you reach the necessary performance.

So, use the tools that let you get the development work done most correctly and most quickly, then use real data to determine where you need to optimize. It could be that C is the most appropriate tool to start with sometimes, but certainly not always, even in embedded systems.

---

Related Topics