And why would you use C++ in embedded.
You are working with limited program memory and limited data memory, why waste it on al the overhead it might bring.
The same goes for using malloc for that matter. For most of the embedded code it is known how much memory is needed and it is carefully planned what goes where.
For me plain C is much easier to read. No hidden functionality you have to dig for. But Java I find even worse. Whats up with the "class.sub_class.yet_another_class.function()" crap
that you don't understand something and think it is too complicated doesn't necessarily mean that it is bad/bloated/wasteful, it just means you don't understand it...
What makes you think I don't understand C++. (Or Java for that matter)
I have used it enough to know how it works and that I don't like using it on embedded systems.
The confusion is here: people disagree about what C++ means.
Those who use it in embedded use a minimalistic subset, removing all features that do not work well on embedded; for example, C++ exceptions.
If you are familiar with C++ application development and have seen "full" C++ being used, it is no wonder using it in embedded seems crazy.
In embedded, basically they use just the class system with constructors, not even destructors because usually you use C++ in embedded to just init with a tad less writing, but never want to deinit, so objects are either global, or in main() so that they never go out of scope because of the infinite loop.
Once you want full control where you init and deinit things dynamically, as in many of my projects, you do it in C because you want to control exactly what deinits() and WHERE, and in which order, because of shared resources, nasty cross-dependencies, and timing constraints. For similar reason, linux kernel is in C, not C++. C++ allows some nice abstractions, but it's exactly those nice abstractions which also fall apart when the use case becomes slightly unexpected. A true C++ pro is always able to somehow manage everything in C++, but us mere mortals then become unable to read their code and participate, because the class interactions can become very complex.
The purpose to use C++ is to change the simple and readable 8 LoC C code into 15% simpler and 20% more readable 6 LoC C++ code, as demonstrated above by cv007. For this to look convincing, you have to ignore the work that went into writing the class implementation, which is much longer than the C equivalent, and also has quite some boilerplate in it. But sure enough, you "only need to do it once", and sure enough, for simple static cases, it sure does optimize to the same machine code.
Some embedded C++ examples indeed look very good, there clearly is potential. But I still think an embedded C++ developer as a risk factor. Best case, C++ is "only in the name", or opposite kind of best case, the nice C++ abstractions happen to work with the project very well. Worst case - you have expanding unmaintainable mess with one rockstar C++ developer who is driven over by a bus.
I think Linus Torvalds' description of C++ applies to embedded as well:
inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.
This is the general problem with object-oriented languages used to their "fullest", with cathedral-like class hierarchy design, often designed with tools like UML.
Set of simple procedural functions with less built-in interdependency, spread over a few modules, does not look nearly as fancy, but also carries less risk and offers more opportunities for modification and reuse, even if the project scope isn't exactly as planned.