One can be an adequate embedded developer using C. But for those trained in OOD C++ can provide a boost in productivity. In my experience this boost can have a positive influence on job satisfaction. It also can, in theory, provide an avenue for a competitor to eat your lunch.

Unfortunately C++ may be rejected by those who are victims of poorly thought-out applications of it in practice. I've seen plenty of nightmares. We've all probably seen that in C as well. For example, just because you can use namespaces to delineate your massive class hierarchy doesn't mean you should. Templates and exceptions are often poorly applied and lead to frustration. I like to think of C++ as a superset of C, so any C code is for the most part C++. Classes and inheritance, along with the benefit of function overloading are really nice additions to the language. If you know how to use them, and that takes training, especially if one can learn from someone that knows how to do it right.

Good points. I just think that the boost in software productivity for larger projects doesn't scale well into the smaller embedded domain with lots of hardware state complexity instead of algorithmic complexity and asynchronous interaction of complex abstract data objects. Efficient hardware implementation is the primary goal. If C types actually thought that native C++ would reduce the time it took to design the software for a complete bare-metal embedded system from scratch most would be on it like ducks on a June bug but we really don't see much enthusiasm for that. The learning it right part is important as there are 40 ways to do something in C++ but maybe only a few ways that actually can provide a boost in productivity when things go bad.

Linux is written in C ( C being effectively portable assembly) and is at least somewhat responsible for the aversion to C++ for SoC development as almost every new system boots and uses some version of Linux as the base embedded OS. The Linux C based abstract machine seems sufficient for just about any hardware related task (writing programs for gadgets) with a large library of working C examples.

 

....

But, I will at all costs avoid exceptions and templates if possible. And namespaces.

Would you mind telling me a bit more why you want to avoid those? I am very keen to know as I am leaning to use C++ in an embedded system. Thanks a lot!

 

As with most things development related, I find it not a good idea to say never. There are often corner cases where life might actually be easier if you do things you don't normally do.

That said; exceptions and templates can possibly lead to larger code (more memory required), depending on how they are written and used. I don't see a reason not to use namespaces, other than they may add unneeded complexity to a relatively small project.

 

Would you mind telling me a bit more why you want to avoid those? I am very keen to know as I am leaning to use C++ in an embedded system. Thanks a lot!

While namespaces seem like a good idea, I've seen in practice they seem to have the opposite of the intended result. In most cases you can avoid name overlap by using a different ID for a function or variable. I think the worst scenario uses multiple nested namespaces.

Templates also seem a good idea, and have their place. But I've seen it abused to the point of making the language tortuously complicated, and for little or no benefit. Sometimes developers like to prove how clever they are rather than creating clear and accurate code. Iterators come to mind, a popular element of before mentioned C++ libraries. Really? Just use the tried and true for(i=0;i<n;i++).

I've mentioned that function overloading is a nice addition to the language. But I'd argue that overloading the pointer dereference is somewhat evil. I've seen it used for reference counting in hopes of achieving automatic memory deallocation (garbage collection) and it made debugging a nightmare.

Exceptions are Goto's from hell. Originally exceptions were designed for really obscure hardware type failures requiring extreme mitigation to handle safely. In practice people use them as normal function semantics rather than returning a success flag or enum. Code becomes bloated with try/catch clauses. If a function encounters a pathological condition, return an error flag and leave it to the caller to deal with it. Throwing an exception and hoping some function call further up the stack will handle it is dangerous and just poor design IMO.

 

Here are examples I've cherry picked from a project I participated in.

::x::Service::Pointer list_serve( xxlib::service::x::Namespace::entry::list::create() );

return  ::boost::xmath::policies::detail::raise_a_domain_error(
           func, msg, avalue,  ::boost::xmath::policies::domain_error< ::boost::math::policies::errno_on_error>());

Imagine a hundred source files saturated with this sort of thing. I tolerated it, but was never convinced this was good design.

 

Here are examples I've cherry picked from a project I participated in.

::x::Service::Pointer list_serve( xxlib::service::x::Namespace::entry::list::create() );

return  ::boost::xmath::policies::detail::raise_a_domain_error(
           func, msg, avalue,  ::boost::xmath::policies::domain_error< ::boost::math::policies::errno_on_error>());

Imagine a hundred source files saturated with this sort of thing. I tolerated it, but was never convinced this was good design.

This does look bad!