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

Question

Question

I have two compilers on my hardware C++ and C89

I\'m thinking about using C++ with classes but without polymorphism (to avoid vtables). The main r

Answer 1

I've just found an example how to use ISO C++ for embedded development, that could interesting for someone that is making the decision whenever use C++ or C.

It was provided by Bjarne Stroustrup at his homepage:

For a look at how ISO C++ can be used for serious embedded systems programming, see the JSF air vehicle C++ coding standards.

Answer 2

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.

Answer 3

For memory allocation issue, I can recommend using Quantum Platform and its state machine approach, as it allocates everything you'd need at the initialization time. It also helps to alleviate contention problems.

This product runs on both C and C++.

Answer 4

For a system constrained to 4K of ram, I would use C, not C++, just so that you can be sure to see everything that's going on. The thing with C++, is that it's very easy to use far more resources (both CPU and memory) than it looks like glancing at the code. (Oh, I'll just create another BlerfObject to do that...whoops! out of memory!)

You can do it in C++, as already mentioned (no RTTI, no vtables, etc, etc), but you'll spend as much time making sure your C++ usage doesn't get away from you as you would doing the equivalent in C.

Answer 5

The book C++ for Game Programmers has information related to when code size will increased based on features from C++.

Answer 6

My choice is usually determined by the C library we decide to use, which is selected based on what the device needs to do. So, 9/10 times .. it ends up being uclibc or newlib and C. The kernel we use is a big influence on this too, or if we're writing our own kernel.

Its also a choice of common ground. Most good C programmers have no problem using C++ (even though many complain the entire time that they use it) .. but I have not found the reverse to be true (in my experience).

On a project we're working on (that involves a ground up kernel), most things are done in C, however a small network stack was implemented in C++, because it was just easier and less problematic to implement networking using C++.

The end result is, the device will either work and pass acceptance tests or it won't. If you can implement foo in xx stack and yy heap constraints using language z, go for it, use whatever makes you more productive.

My personal preference is C because :

• I know what every line of code is doing (and costs)
• I don't know C++ well enough to know what every line of code is doing (and costs)

Yes, I am comfortable with C++, but I don't know it as well as I do standard C.

Now if you can say the reverse of that, well, use what you know :) If it works, passes tests, etc .. what's the problem?