Which is better for embedded work: C or C++?

[PuterGeek]

...C is almost always the best for embedded code...

I would modify this to C is almost always used for embedded code. Very few engineers even know C++ nor the plusses or minuses of each.

C++ can bloat code if every possible feature is used. C can bloat code if poorly designed or implemented. In fact all languages from assembly to the latest super language can be used to write bloated, crappy code.

Of course any language can also be used to write excellent, compact code. The difference in excellent and crappy largely comes down to appropriate use of tools and experience.

My recommendation would be appropriate use of C++ with good coding standards such as the JSF C++ Coding Standards (http://www.jsf.mil/downloads/documents/JSF_AV_C++_Coding_Standards_Rev_C.doc).

If C code is required, using a C++ compiler (if available) is recommended because of better compile time checking. Using a coding standard with C such as MISRA C (http://www.misra.org.uk/MISRAHome/MISRAC2012/tabid/196/Default.aspx) helps avoid some of the lurking dangers and generally produces more robust code.

[Kremmen]

IDE: Atmel Studio is amazing value for money (free) as you get both the Visual Studio editor and Visual Assist X. It is by far the best free embedded IDE currently available IMHO.

Agree, as i too noted in some other threads.

C/C++: C is almost always the best best for embedded code.

That is not necessarily the case. What would be the rationale for so sweeping a statement?

You can get away with C++ if you limit the features you use and fully understand the implications, but most of what you can use is just making up for a lack of organization and discipline on the programmer's side.

Actually, you get away with using C++ if your environment supports all the features you wish to use. Failing that you need to limit the more advanced features, which is often the case, but not a show stopper or usually even a major inconvenience. As for implications, i have to say that in the environments i use there don't seem to be any particular implications. Care to specify what exactly those would be.
An unorganized programmer can be so / will be so regardless of the language used. I have seen horrible C code where the only possible reward is a swift kick in the culprit's butt, as well as C++ that is close to poetic in its refinement. And everything in between and vice versa. Language selection is not a question of discipline or otherwise.

Namespaces are a classic example. If you name stuff properly in C they add no benefit, while allowing you to complicate the scope of things. You end up with loads of pointless getter/setter functions, sorry methods, when it would be better to just use appropriate names. For example I use _SIG for signals that must only be set or cleared and _AT for variables that must be accessed atomically for interrupt safety (i.e. turn off interrupts while accessing them).

Getters and setters are there for a reason. Actually the trivial implementation does not add anything over C because it will be an identical inline assignment / read. But a great benefit if you need to add side effects later, which you so often do.
You can roll your own name rules but now you have introduced an ad hoc standard for naming convention. How is that superior to using the built in mechanism in a standard environment?

I don't know any commercial programmers who use C++ for microcontrollers. On ARM you can get away with it.

Because so many commercial programmers just do it for the money, with no ambition or true interest. There is no need to be good at what you do, just to pass the absolutely minimum to get the project out the door and invoices into the mailbox.
OK, i exaggerate but my point is that commercial companies lack the motivation to progress beyond what is minimum necessary to get the job done. If C worked yesterday let's hope it will keep on working tomorrow and not rock the boat.

Remember - all growth takes place out of the comfort zone. After 30+ years of being a programmer and manager of programmers myself, i decided to try C++ in embedded hobby projects. Sure, you can't get every OO feature in a lowly AVR that you can get in a Solaris or HP-UX or big Wintel server, but then you don't want to either. Nevertheless, boy what a difference C++ makes in code organization and reuse. For me no going back to the ball and chain that is C. But YMMV.

[benemorius]

Nevertheless, boy what a difference C++ makes in code organization and reuse. For me no going back to the ball and chain that is C. But YMMV.

I feel the need to second this and encourage anyone in an applicable position to give it at least one fair chance before deciding one way or the other.

Not having tight-ass MBAs hovering over my head I may be the exception, but I would increase the budget to make room for a more capable micro (overkill accusations notwithstanding) before I went back to vanilla C. The convenience is worth every penny and I just can't see myself going back. Writing and maintaining firmware became fun again once I gave C++ a try.

[mrflibble]

Nevertheless, boy what a difference C++ makes in code organization and reuse. For me no going back to the ball and chain that is C. But YMMV.

I feel the need to second this and encourage anyone in an applicable position to give it at least one fair chance before deciding one way or the other.

Guess I'll third that. Lately I'm playing around with both C++ and ChibiOS to see what works and what doesn't, and so far I am liking it. C++ really makes things a lot more organized for a minimum of effort. As opposed to C where you can also make things nice and organized, but that does take more work. And not to start a seperate RTOS or plain single threaded huge main() loop / roll your own threading ... I must say so far chibios is damn nice. I also checked freertos a bit, but decided to go with chibios. Not in the least because the stm32 support looks to be pretty good.

On the subject of constructors ... how do you guys handle that for embedded? Right now I have static objects with public constructors so it's known at compile time. Constructors get called in random order at run time before main() entry ... so I only do some simple things like internal variable bookkeeping there. Any order dependant things like hardware initialization I plunk in an Init() method which then gets called in the proper order from main(). That seemed a bit more sensible than putting hardware config in the constructors and then somehow (crt0.o ?) forcing a specific order. Is that the right way to go about things or are there better alternatives?

[andyturk]

On the subject of constructors ... how do you guys handle that for embedded? Right now I have static objects with public constructors so it's known at compile time. Constructors get called in random order at run time before main() entry ... so I only do some simple things like internal variable bookkeeping there. Any order dependant things like hardware initialization I plunk in an Init() method which then gets called in the proper order from main(). That seemed a bit more sensible than putting hardware config in the constructors and then somehow (crt0.o ?) forcing a specific order. Is that the right way to go about things or are there better alternatives?

I try to have only a few objects hanging out at the "top level", since that's where the init order becomes unpredictable. Sometimes I'll just have a big Application object that keeps all of its state in member variables (e.g., a display buffer, ADC data buffer, threads, etc.). Within a class, initialization order is well defined.

When all else fails, there's always __attribute__ ((init_priority(X))).

I do the same kind of thing with init() methods. If you're flipping GPIOs and setting up hardware, you probably don't want that stuff happening in a constructor before main() is called or, for example, before clocks are set up.

[Kremmen]

On the subject of constructors ... how do you guys handle that for embedded? Right now I have static objects with public constructors so it's known at compile time. Constructors get called in random order at run time before main() entry ... so I only do some simple things like internal variable bookkeeping there. Any order dependant things like hardware initialization I plunk in an Init() method which then gets called in the proper order from main(). That seemed a bit more sensible than putting hardware config in the constructors and then somehow (crt0.o ?) forcing a specific order. Is that the right way to go about things or are there better alternatives?

Don't know about something being more right than something else. I tend to do exactly what you are doing. init_priority is the method supported by the environment (at least gcc) and that would be the way i guess, if you dont want to / can't init() from main. Of course the alternative is to construct the objects at runtime using new(). Then that question does not raise its head but dynamic memory allocation may not always be a good idea, at least in safety critical applications. That said, i have used dynamic object trees for e.g. activity sequencing and runtime sequence editing with no problems. Actually the code for that was very clean if i may say so myself.

[mrflibble]

If you're flipping GPIOs and setting up hardware, you probably don't want that stuff happening in a constructor before main() is called or, for example, before clocks are set up.

That was pretty much my thinking as well. Plus, reading the order of Init() calls in main() is probably a bit more transparent than a bunch of init_priorities. Both easier for future me as well as other hapless victims.

And for the current chibios stuff this choice is even easier, since I'd like to call my Init()'s after halInit() has been called.

[vvanders]

On the subject of constructors ... how do you guys handle that for embedded? Right now I have static objects with public constructors so it's known at compile time. Constructors get called in random order at run time before main() entry ... so I only do some simple things like internal variable bookkeeping there. Any order dependant things like hardware initialization I plunk in an Init() method which then gets called in the proper order from main(). That seemed a bit more sensible than putting hardware config in the constructors and then somehow (crt0.o ?) forcing a specific order. Is that the right way to go about things or are there better alternatives?

Pretty much, anything more than trivial value initialization shouldn't be done in constructors. Initialization should be done explicitly to control the order of things, static globals with non-trivial constructors as a recipe for disaster.

[mrflibble]

I guess this is why some people actually RTFM and verify on a forum to be aware of limitations, and then work accordingly. But whatever floats your boat, if you like C stick with it. As for C++ being fault inducing ... not to worry, you don't need C++ for that. I've seen all manner of crap, asm, C, C++. And I've seen all manner of good code, asm, C, C++.

Easy to follow plan:
1 - pick right tool for the job
2 - don't suck at using this tool
3 - profit

[Kremmen]

Constructors are basically useless. What can you do with them? Set some default values... Well, you can just do that when the variables are defined. Can't allocate anything non-static anyway. Can't set up any hardware before main() has run, and running order isn't guaranteed.

Oh please. Now you erected a straw man and kicked it down. While it is true that for a trivial object you don't need much of a constructor, that doesn't mean constructors (and destructors) are useless. Static class instances don't go in and out of scope so construction and destruction are not relevant for them in the same way as for true dynamic instances, but that is not at all a problem of the construction mechanism, so criticizing it misses the mark.

This is what I mean about C++ causing problems because people aren't fully aware of the consequences of trying to use certain features. With static constructors it isn't even possible to tell what order start-up code will execute in.

I guess this is why some people actually RTFM [...]

2 - don't suck at using this tool

[...]

This is the solution.

[Rufus]

Constructors are basically useless. What can you do with them? Set some default values... Well, you can just do that when the variables are defined.

Some people just don't get OOP which makes me question their ability to get anything really.

As for constructing statics, allocating something once at start up and never freeing it isn't dynamic and should be of no concern in embedded systems. A heap manager which doesn't have to free anything can be implemented in 3-4 lines of code. There is also placement new which no one mentioned yet.

[ToBeFrank]

Constructors are basically useless. What can you do with them? Set some default values... Well, you can just do that when the variables are defined.

Only if you're using C++11.

[Jeroen3]

Our DSP teacher has said more then a few times that the C++ compiler creates better assembler then the C compiler. Not sure in what area of better, faster or smaller?
But it makes complete sense to use C++ for all the bonus features you will get above C. Like templates types, objects, overloading, default arguments.
Using object oriented in C with structures doesn't compete with C++ with coding comfort. .

And also, looking at micro controllers, every peripheral can be an object, including driver code. Instead of a structure of registers, and driver functions separate.

However, when using C++ with fancy dynamic memory you don't want to end up creating a lot of objects on stack (eg. inside a function) that's incredibly slow!
And you should definitely be aware that your few kB of sram are very limited.

In the end it does not matter a lot, if you give the compiler and optimizer enough hints it can make efficient assembler.
That is the main goal for micro controller programmers, compiling efficient code. This can be done with C or C++, choose the one that gives you most comfort.

^{Also, I've seen the term "x lines of code". One line of code can take up quite a lot of cpu time. For example this: "volatile double x *= 6.5444;". It's "just one line", but is can take more than 1KB of instructions on some architectures.}

[ToBeFrank]

However, when using C++ with fancy dynamic memory you don't want to end up creating a lot of objects on stack (eg. inside a function) that's incredibly slow!

I think you meant this but for clarification... allocating objects on the stack in C++ is the same speed as in C (a class is essentially a struct). If the object being allocated uses dynamic memory in its constructor, the allocation on the stack would be slow, but otherwise stack allocation is very fast.

[ToBeFrank]

You can't rely on constructors because sometimes you need to set stuff up in sequence after other things, so you will end up with a mix of constructors that execute in random order and a load of init() methods you then call later.

More clarification... class member variable constructors are called in the order the member variables were declared. Static initializers have no guaranteed order.

[nctnico]

Oh please. Now you erected a straw man and kicked it down. While it is true that for a trivial object you don't need much of a constructor, that doesn't mean constructors (and destructors) are useless. Static class instances don't go in and out of scope so construction and destruction are not relevant for them in the same way as for true dynamic instances, but that is not at all a problem of the construction mechanism, so criticizing it misses the mark.

You are thinking too abstractly, which is exactly what I was talking about. You say the construction mechanism itself is not a problem which is in some sense true. The problem is you can't separate the abstract concept of the constructor mechanism and the practical implementation in an embedded system. It works on the desktop, but not for embedded.

You clearly have the concepts wrong. A constructor which doesn't construct anything is an empty function which is optimised away. Secondly the others already stated that they instantiate the objects statically which means there is no dynamic memory usage other than the stack which you have with C as well. All in all your objections have no ground.

[cthree]

Constructors aren't useless, they just aren't very useful.

C++ is something of an ugly implementation of OO in my personal opinion, second only to Java.

[Rufus]

<snip another straw man argument>

What you are actually saying is you don't know how much stack is required but while the compiler spits out a number which makes the stack space look big you are not bothered about it and if someone reduces memory available for the stack in the future it is their responsibility to check the number the compiler spits out and make some value judgement and worry about it. If they don't ("because they thought they were safe or didn't understand the implications of what they were doing") they get just the same horrid stack/variable overwriting bugs which you attribute to heap memory allocation on start up.

[Kremmen]

Oh please. Now you erected a straw man and kicked it down. While it is true that for a trivial object you don't need much of a constructor, that doesn't mean constructors (and destructors) are useless. Static class instances don't go in and out of scope so construction and destruction are not relevant for them in the same way as for true dynamic instances, but that is not at all a problem of the construction mechanism, so criticizing it misses the mark.

You are thinking too abstractly, which is exactly what I was talking about. You say the construction mechanism itself is not a problem which is in some sense true. The problem is you can't separate the abstract concept of the constructor mechanism and the practical implementation in an embedded system. It works on the desktop, but not for embedded.

All the constructor will do is add bloat. You can't rely on constructors because sometimes you need to set stuff up in sequence after other things, so you will end up with a mix of constructors that execute in random order and a load of init() methods you then call later. You might as well just stick everything in the init() methods.

Sure, an object instance must be constructed but why is that a problem? You are free to influence the actual construction in a number of ways, such as defining all instances static if you really don't want to do anything during runtime. But if you do choose to create objects during runtime, they must be constructed at least in the minimal way of allocating the space for member variables. That part you cannot separate (and why would you want to?) but everything else can be put in a separate init() method that you are free to call if and whenever you want to. Contrary to what you imply it is not at all rare in desktop and server environments either. It is just a question of what is practical. Because if you _don't_ want to use init()s then just define init_priority and be done with it.
Much is made now of this initialization order and for MCU hardware it sometimes (but not always and in every case) matters. That particular problem is easily solved in a number of ways. Otherwise the question of construction order is either uninteresting or defined by control flow and scope visibility.

People don't like doing that though because on the desktop the paradigm is to always do certain things in the constructor because then by convention people know where to find them. It just don't work for embedded.

The paradigm of construction comes from the language definition, not from what "people like to do". Constructor is the place to initialize a class instance and there should be a reason not to do it there. Using the init() method is potentially risky if only a default constructor is used since then the member variables might be uninitialized. Accidentally calling a method before init() could cause problems. The really proper way for static, order dependent instances would be to implement a minimal constructor that puts the instance into a coherent state, and then later call the init().
I have yet to find out how construction doesn't work for the embedded software since it patently does. Yes, there is a cost to construction but the minimal cost is not really any different from allocating a struct in C. Calling that bloat is IMO unjustified. Anything else a constructor does is application code and needs doing anyway so is by default excluded from any language caused bloat. At this very reasonable cost you get all the benefits of potentially polymorphic object creation shifting the balance easily to C++ as far as i am concerned.

For some reason the discussion of constructors revolves only around initializing member variables. Sure, that always happens but it is not at all the only thing a constructor is good for. The recurring "problem" of dynamic memory allocation is supposed to lead to disaster always in the end. It is supposed to be so hard to detect when the system runs out of memory yada yada. Sure, keep allocating memory and eventually you will run out. However it is not like you can't do anything to avoid running into a brick wall at full throttle. Firstly, not all dynamic allocations just keep piling up. You might wish to construct alternative versions of an object, but only a limited number or just one at a time. Second, if you do need to allocate an unknown number of instances and you absolutely must not run out of memory (at least without realizing it), there are ways. The way i would choose is a class factory design pattern. The static factory instances allocate a fixed block of memory (yes) and use that to dish out memory for the instances they create by request. Now if you run out of memory in the block the program doesn't just crash. The factory can either just inform the caller of this sad state of affairs, or it can negotiate more memory for itself, should any be available and fulfill the request. Its all quite doable with less lines of code you might think. The nice thing is that it is configurable to do what makes sense in each particular application so code reuse is high. Effectively it does just what a vanilla C allocator does, but hiding the implementation from the calling party, thus making the caller independent of the solution - exactly the point of reuse. Plus, you are free to decide on a recovery strategy if that is wanted - something that would be at least cumbersome to arrange in C code.
But then you can always pre-allocate everything in the old fashioned way. It is equally secure but you need to hope you got your allocation ratios right. It would be sad if one pool is exhausted stopping the application while plenty of free memory remains available in other pools.

[Jeroen3]

In embedded application, especially automotive or other certified, you don't want to be able to create an unknown number of instances of an object. You always want your memory usage to be predictable.

You can perfectly dynamically create a static task. *huh what?*
Just create a fixed number and never delete them.

And take for exmaple a sprintf buffer, you only need that for a short while, in a task. If you can guarantee the buffer is freed when the task is completed and your buffer operations cannot be rescheduled, you'll have low change of getting memory trouble. After the sprintf task you can then use that memory for an SD card task for example.

But the safest possible way is to pre-allocate everything.

To the constructors, they are just functions called when the object is allocated to initialize stuff. Even your "int main(void)" has a constructor, its called startup.s.
If you have normal C you'd have a bunch of "struct thingy_1" with "thingy_init(thingy_1)". Same story.

[Rufus]

No, I'm saying that you can calculate exactly how much stack space is required by any given program as long as everything is statically allocated and you don't do any unbound recursion.

Variables being allocated statically or dynamically has a tiny influence on stack requirement and zero influence on the difficulty of calculating exact stack requirements.

[andyturk]

When you statically allocate everything by defining it in code and hit the compile button you get number back telling you how much RAM has been allocated. The rest is free for stack. You know exactly how much you have and how close you are to running out. If, five years down the line, someone comes along and decides they need a few hundred bytes for a buffer they will quickly notice that after defining it the available RAM is dangerously low.

On the other hand if you allocate stuff at run-time you could easily end up with insufficient free space.

This is a really good point. In my own mcu code, I try to avoid dynamic memory allocation for this very reason. Sometimes it creeps back in debug builds because of printf, but that's livable.

However, C++ doesn't require dynamic allocation any more than C does, and whichever style of allocation you prefer will work in both language. Personally, I use constructors in C++ frequently in code with statically allocated objects. For example, suppose there's a Display class that draws data from a Buffer. In C++, I'd have the Display constructor accept a const reference to the Buffer:

Code: [Select]

class Display {
  const Buffer &data;

 public:
  Display(const Buffer &b) : data(b) {}
  // other methods here
};

// static variables
Buffer gData;
Display gDisplay(gData);
If I end up changing the name of the Buffer instance, there's no need to modify the Display implementation at all, because the coupling between the classes is very weak. In contrast, most embedded C that I've run across would have the Display functions directly reference the buffer variable with much tighter coupling. To be sure, these are stylistic points, but IMO it's easier to maintain code that separates concerns well, and C++ makes that more easy than C.

[nctnico]

In embedded application, especially automotive or other certified, you don't want to be able to create an unknown number of instances of an object. You always want your memory usage to be predictable.

You can perfectly dynamically create a static task. *huh what?*
Just create a fixed number and never delete them.

Thats another way to do it. The whole point is that you need to create a situation in which the memory usage is 100% predictable.

[vvanders]

However, C++ doesn't require dynamic allocation any more than C does, and whichever style of allocation you prefer will work in both language.

This right here. There's a lot of straw man arguments being thrown around about constructors, they're no different than init functions. The issue becomes with statically declared objects that don't have an well defined initialization order. Hence the need to separate out any code that cares about sequencing vs default value initialization.

I come from the games space where performance and memory is just as critical as in the MCU space. You've got 16.6ms to update thousands of objects, and render them. You're constantly pushing against memory limits to hit the best fidelity that you can get. Every engine I've worked with that's hit this target has:

• Used C++
• Not done dynamic memory allocation

Using fixed pooled allocators with placement new you can get completely predictable memory usage and all of the benefits that come with C++. Hell, I've even seen scripting languages used inside of 400kb fixed space allocation. I'm talking about shipped products here and not just hobby projects.

Since C++ is just a superset of C it's not the language but how you choose to used it.

[Kremmen]

The paradigm of construction comes from the language definition

That is the problem. The paradigm is designed for systems where things are dynamically allocated. Shoe-horning it into an embedded system isn't a good idea.

The border between "embedded" and general purpose is a line somewhat drawn in water. For sure Stroustrup & co never made such a distinction. Nowhere in the language is there a requirement to allocate anything dynamically so using that as an argument against the language again misses the mark. Please don't make dynamic allocation a required feature of C++ which you can then shoot down and thereby dismiss the language in embedded solutions. It just isn't so.
I largely agree with those who warn against careless use of dynamic memory in resource constrained systems but that is not a problem of the language, only its usage.
I hope it is by now obvious to all that offhand dismissing something that is actually widely used with good success is not a fact but opinion only. We are all entitled to those of course.