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

Error processing SSI file


  1. Ferrari

    • 2015/11/5

    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.

  2. Steven

    • 2021/9/18

    Another time/reason to use C is to provide a set of functions that you can bind to from essentially any other language.

  3. Kareem

    • 2020/11/30

    A good reason and sometimes the only reason is that there is still no C++ compiler for the specific embedded system. This is the case for example for Microchip PIC micro-controllers. They are very easy to write for and they have a free C compiler (actually, a slight variant of C) but there is no C++ compiler in sight.

  4. Zayne

    • 2016/7/26

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

  5. Maurice

    • 2018/12/4

    The Technical Report on C++ Performance is a great guide for this sort of thing. Note that it has a section on embedded programming concerns!

    Also, ++ on the mention of Embedded C++ in the answers. The standard is not 100% to my tastes, but it is a good bit of reference when deciding what parts of C++ you might drop.

    While programming for small platforms, we disable exceptions and RTTI, avoided virtual inheritance, and paid close attention to the number of virtual functions we have lying around.

    Your friend is the linker map, though: check it frequently, and you'll spot sources of code and static memory bloat quickly.

    After that, the standard dynamic memory usage considerations apply: in an environment as restricted as the one you mention, you may want to not use dynamic allocations at all. Sometimes you can get away with memory pools for small dynamic allocs, or "frame-based" allocation where you preallocate a block and throw out the whole thing later.

  6. Clay

    • 2021/2/8

    The C++ standard library (STL), in itself with just vectors and maps, is reason enough to use C++. C is commonly used for embedded systems. I would personally use C only if there is some library that has only a C API.

  7. Leonel

    • 2016/9/25

    C is almost exclusively used for embeded coding and legacy coding. This is because making a C compiler is far easier than a C++ compiler, hence 

  8. Parker

    • 2018/1/24

    Answer (1 of 13): For many years, programmers existed who knew lots of C and were learning C++. People hiring C++ developers needed to look through both C and C++ devs.

  9. Bruno

    • 2020/12/10

    I recommend using the C++ compiler, but limiting your use of C++ specific features. You can program like C in C++ (the C runtime is included when doing C++, though in most embedded applications you don't make use of the standard library anyway).

    You can go ahead and use C++ classes etc., just

    • Limit your use of virtual functions (as you've said)
    • Limit your use of templates
    • For an embedded platform, you'll want to override the operator new and/or use placement new for memory allocation.
  10. Nehemiah

    • 2016/7/21

    Having said that, there are definitely good reasons to use pure C. As one example, most programming languages with a foreign function interface support C and 

  11. Martinelli

    • 2016/8/14

    There are plenty of reasons to believe that C programming will remain active for a long time. Here are some reasons that C is unbeatable, and almost mandatory, for certain applications. Daniel has created high-performance applications in C++ for large companies such as Dreamworks. He also excels with C and ASM (x86).

  12. Dawson

    • 2018/12/26

    Of course, both programming languages have their own advantages and drawbacks over one another. To provide you with an overview of C vs C++, 

  13. Parisi

    • 2015/4/27

    For a very resource constrained target such as 4KB of RAM, I'd test the waters with some samples before committing a lot of effort that can't be easily ported back into a pure ANSI C implementation.

    The Embedded C++ working group did propose a standard subset of the language and a standard subset of the standard library to go with it. I lost track of that effort when the C User's Journal died, unfortunately. It looks like there is an article at Wikipedia, and that the committee still exists.

    In an embedded environment, you really have to be careful about memory allocation. To enforce that care, you may need to define the global operator new() and its friends to something that can't be even linked so that you know it isn't used. Placement new on the other hand is likely to be your friend, when used judiciously along with a stable, thread-safe, and latency guaranteed allocation scheme.

    Inlined functions won't cause much problem, unless they are big enough that they should have been true functions in the first place. Of course the macros their replacing had that same issue.

    Templates, too, may not cause a problem unless their instantiation runs amok. For any template you do use, audit your generated code (the link map may have sufficient clues) to make certain that only the instantiations you intended to use happened.

    One other issue that may arise is compatibility with your debugger. It isn't unusual for an otherwise usable hardware debugger to have very limited support for interaction with the original source code. If you effectively must debug in assembly, then the interesting name mangling of C++ can add extra confusion to the task.

    RTTI, dynamic casts, multiple inheritance, heavy polymorphism, and exceptions all come with some amount of runtime cost for their use. A few of those features level that cost over the whole program if they are used, others just increase the weight of classes that need them. Know the difference, and choose advanced features wisely with full knowledge of at least a cursory cost/benefit analysis.

    In an small embedded environment you will either be linking directly to a real time kernel or running directly on the hardware. Either way, you will need to make certain that your runtime startup code handles C++ specific startup chores correctly. This might be as simple as making sure to use the right linker options, but since it is common to have direct control over the source to the power on reset entry point, you might need to audit that to make certain that it does everything. For example, on a ColdFire platform I worked on, the dev tools shipped with a CRT0.S module that had the C++ initializers present but comment out. If I had used it straight from the box, I would have been mystified by global objects whose constructors had never run at all.

    Also, in an embedded environment, it is often necessary to initialize hardware devices before they can be used, and if there is no OS and no boot loader, then it is your code that does that. You will need to remember that constructors for global objects are run before main() is called so you will need to modify your local CRT0.S (or its equivalent) to get that hardware initialization done before the global constructors themselves are called. Obviously, the top of main() is way too late.

  14. Shehu

    • 2019/10/28

    C is dumb but once you teach her, she will rock. Nothing much has changed after the C99 version. The best advantage of using C instead of C++ is that you can write your code or program very effectively and with ease and debug it easily. The portability of C is great. You can literally impliment any logic in your program.

  15. Aarav

    • 2018/8/29

    Then, the core of Unix was modified to run on C. At its core, C is a general-purpose, compiled, and procedural programming language.

  16. Colter

    • 2020/4/6

    Just to remind you of lordofduct's post above, you CAN code in any language that .NET supports, and that includes C++/CLI, which basically is C++. If all you care about is using "&" instead of "ref" and other clunky C++ syntax, then it will get you what you want. If you want to use a bunch of native DLL's from other places, it won't help though.

  17. Huxley

    • 2018/12/28

    No. Any of the C++ language features that could cause problems (runtime polymorphism, RTTI, etc.) can be avoided while doing embedded development. There is a community of embedded C++ developers (I remember reading columns by embedded developers using C++ in the old C/C++ Users' Journal), and I can't imagine they'd be very vocal if the choice was that bad.

  18. Gunnar

    • 2017/9/2

    Many people claim that C++ is better than C and many the other way round. However, the general belief is that it is good to switch to C++ 

  19. Cory

    • 2021/9/7

    Using sizeof T would expect T to be an expression and not a type, and thus the example would not compile with C++. Linking C and C++ code[edit]. While C and C++ 

  20. Abdiel

    • 2021/3/3

    The GNU operating system itself was started using C and Lisp programming Many C projects are still started today; there are some good reasons for that.

  21. Riley

    • 2020/9/1

    C is a general-purpose, procedural programming language. Being general-purpose Let's take a look at some of the use cases for C and C++.

Comments are closed.

More Posts