A common question, here and elsewhere. Is C++ suitable for embedded systems?
Microcontrollers? RTOSes? Toasters? Embedded PCs?
Is OOP useful on microcontrollers?
Does C++ remove the programmer too far from the hardware to be efficient?
Should Arduino's C++ (with no dynamic memory management, templates, exceptions) be considered as "real C++"?
(Hopefully, this wiki will serve as a place to contain this potential holy war)
Yes, C++ is still useful in embedded systems. As everyone else has said, it still depends on the system itself, like an 8-bit uC would probably be a no-no in my book even though there is a compiler out there and some people do it (shudder). There's still an advantage to using C++ even when you scale it down to something like "C+" even in a 8-bit micro world. What do I mean by "C+"? I mean don't use new/delete, avoid exceptions, avoid virtual classes with inheritance, possibly avoid inheritance all together, be very careful with templates, use inline functions instead of macros, and use const variables instead of #defines.
I've been working both in C and C++ in embedded systems for well over a decade now, and some of my youthful enthusiasm for C++ has definitely worn off due to some real world problems that shake one's naivete. I have seen the worst of C++ in an embedded systems which I would like to refer to as "CS programmers gone wild in an EE world." In fact, that is something I'm working on with my client to improve this one codebase they have among others.
The danger of C++ is because it's a very very powerful tool much like a two-edged sword that can cut both your arm and leg off if not educated and disciplined properly in it's language and general programming itself. C is more like a single-edged sword, but still just as sharp. With C++ it's too easy to get very high-levels of abstraction and create obfuscated interfaces that become meaningless in the long-term, and that's partly due to C++ flexibility in solving the same problem with many different language features(templates, OOP, procedural, RTTI, OOP+templates, overloading, inlining).
I finished a two 4-hour seminars on Embedded Software in C++ by the C++ guru, Scott Meyers. He pointed out some things about templates that I never considered before and how much more they can help creating safety-critical code. The jist of it is, you can't have dead code in software that has to meet stringent safety-critical code requirements. Templates can help you accomplish this, since the compiler only creates the code it needs when instantiating templates. However, one must become more thoroughly educated in their use to design correctly for this feature which is harder to accomplish in C because linkers don't always optimize dead code. He also demonstrated a feature of templates that could only be accomplished in C++ and would have kept the Mars Climate Observer from crashing had NASA implemented a similar system to protect units of measurement in the calculations.
Scott Meyers is a very big proponent on templates and judicious use of inlining, and I must say I'm still skeptical on being gung ho about templates. I tend to shy away from them, even though he says they should only be applied where they become the best tool. He also makes the point that C++ gives you the tools to make really good interfaces that are easy to use right and make it hard to use wrong. Again, that's the hard part. One must come to a level of mastery in C++ before you can know how to apply these features in most efficient way to be the best design solution.
The same goes for OOP. In the embedded world, you must familiarize yourself with what kind of code the compiler is going to spit out to know if you can handle the run-time costs of run-time polymorphism. You need to be willing to make measurements as well to prove your design is going to meet your deadline requirements. Is that new InterruptManager class going to make my interrupt latency too long? There are other forms of polymorphism that may fit your problem better such as link-time polymorphism which C can do as well, but C++ can do through the Pimpl design pattern (Opaque pointer).
I say that all to say, that C++ has its place in the embedded world. You can hate it all you want, but it's not going away. It can be written in a very efficient manner, but it's harder to learn how to do it correctly than with C. It can sometimes work better than C at solving a problem and sometimes expressing a better interface, but again, you've got to educate yourself and not be afraid to learn how.
C++ is absolutely suitable for embedded systems. I now use the presence/absence of good development tools (or lack thereof) as my primary criterion for whether or not to use a particular microprocessor.
Areas of C++ that are good to use on embedded systems because they have low resource costs:
OK areas:
Areas not to use, mostly because of the run-time overhead that is unacceptable on small systems:
foo calls bar within a try/catch block, and bar creates some objects and calls boz, which throws an exception, the system has to somehow call the destructors for the objects bar created before returning control to foo. Unless exceptions are completely disabled, bar will have no way of knowing whether boz might throw any, and must thus include extra code to allow for that possibility. I'd like to see a variation of C++ with "checked exceptions" to deal with that; if routines which could allow exceptions to escape...
\$\endgroup\$
add r15,r14,#2 instead of mov r15,r14; to exit via exception, ldrhs r0,[r14] / add r15,r14,r0. Zero cycle cost for the normal exit, and no stack-frame restrictions.
\$\endgroup\$
Yes, C++ is certainly suitable for embedded systems. First let's clear up a couple of misconceptions about the difference between C and C++:
In an embedded micro, you're always going to need to use high level languages carefully if you're concerned about time or space constraints. For example, many MCUs don't handle pointers well, and so are very inefficient when using the stack. This means that you have to be careful about passing variables to functions, using arrays and pointers, and recursion. A simple line of C like:
a[i] = b[j] * c[k];
can generate about 4 pages of instructions depending on the nature of those variables.
Whenever you're using any high level language, and you're concerned about time and space constraints, then you need to know how every feature of that language translates into machine instructions on your MCU (at least, every feature that you use). This is true for C, C++, Ada, or whatever language you use. Probably all languages will contain features that don't translate efficiently to small MCUs. Always check the disassembly listings to make sure that the compiler's not trivially generating reams of instructions.
Is C suitable for embedded MCUs? Yes, as long as you keep an eye on the generated code.
Is C++ suitable for embedded MCUs? Yes, as long as you keep an eye on the generated code.
Here's why I think that C++ is better than C, even on 8-bit MCUs: C++ provides improved support for:
None of these features are any heavier than typical features of C.
As you move up to 16 or 32 bit MCUs, then it starts to make sense to use heavier features of C (stack, heap, pointers, arrays, printf, etc.) In the same way, on a more powerful MCU, it becomes appropriate to use heavier features of C++ (stack, heap, references, STL, new/delete).
So, there's no need to shudder at the thought of C++ on a PIC16. If you properly know both your language and your MCU, then you will know how to effectively use them both together.
a[i] = b[j] * c[k]; can generate about 4 pages of instructions depending on the nature of those variables." If your MCU/compiler does this, it is because you are using some garage hobbyist CPU from the 80s.
\$\endgroup\$
I always find these debates entertaining to read. Not so much for the intellectual discussion about the pros and cons of the various available languages but because you can usually peg someone's stance on the topic based on their job/experience/area of interest. It's right up there with the "premature optimization" arguments were the CS majors and maintenance programmers quote Knuth left and right and those who work in the real world where performance matters think they're all crazy (I'm a member of the latter group to be fair).
At the end of the day, you can develop excellent software in C or C++ or insert language here. It comes down to the capabilities of the developer not the language. Being an expert in a language is usually only required if you've chosen the wrong language to begin with and now need to warp it into solving your problem, in most cases these are the only situations where you need to dive into obscure features or compiler tricks to accomplish the goal.
I often hear people start these arguments as "I'm an expert in language X and blah blah" I honestly immediately discredit these people because, in my opinion, they've already approached the problem from the wrong angle and everything after that is tainted by their desire to use their tool to solve the problem and show how 'cool' it is.
I so often watch developers choose a tool set first and attempt to bend it to their problem second, which is completely wrong and results in crap solutions.
As I mentioned in a comment to another answer, these language wars often devolve into arguing that language X allows the programmer to do more dumb things. While entertaining to read, all these statements really mean is that you have a problem hiring good developers and need to address that issue directly rather than trying to band aid the situation by continuing to hire bad developers and choosing tools such that they can do as little damage as possible.
In my opinion good developers, be it software or hardware development, research the problem, architect a solution and find the tools that allow them to express the solution in the 'best way'. It shouldn't matter if the required tool is something you've never used before, after you've used 3-4 languages/development tools for projects picking up a new one should have a minimal impact on your development time.
Of course, 'best way' is a subjective term and also needs to be defined in the research phase. One needs to consider a multitude of issues: performance, ease of expression, code density, etc based on the problem at hand. I didn't include maintainability in that list for a reason, I don't care what language you choose, if you've chosen the proper tool and taken the time to understand the problem this should come 'for free'. Difficult to maintain code is often the result of choosing the wrong tool or a poor system structure, this results in an ugly hacky mess to make it work.
Claiming any language is 'better' than any other is silly without defining a particular problem of interest. An object oriented approach is not always better than a functional approach. There are some problems that lend themselves very well to an object oriented design paradigm. There are many that do not. The same statement can be made about many language features that people seem to enjoy harping on.
If you're spending more than 20% of your time on a problem actually typing code, you're probably producing a very poor system, or have very poor developers (or you're still learning). You should be spending the majority of your time up front diagramming the problem and determining how various pieces of the application interact. Sticking a group of talented developers in a room with a marker board and a problem to solve and telling them they are not allowed to write any code or choose any tools until they feel comfortable with the entire system will do more to improve the quality of the output and speed development than choosing any hot new tool guaranteed to improve development time. (look up scrum development as a reference for the polar opposite to my argument)
Often the unfortunate reality is that many businesses can only measure the value of a developer by the number of lines written, or by seeing 'tangible output'. They view the 3 weeks in a room with a marker board as a loss in productivity. Developers are often forced to speed through the 'thought' stage of development or are forced into using a tool set by some political issue within the company, "My boss's brother works for IBM so we can only use their tools", that kind of rubbish. Or worse, you get a constantly changing set of requirements from the company because they are not capable of doing proper market research or don't understand the impact of changes on the development cycle.
Sorry for being slightly off topic with this rant, I have quite strong opinions on this topic.
In my experience, C++ is usually ill-suited to small embedded systems. By which I mean, microcontrollers and OS-less devices.
Many C++ OOP techniques rely on dynamic memory allocation. This is often missing in small systems.
STL and Boost really demonstrate the power of C++, both are huge in footprint.
C++ encourages the programmer to abstract away the machine, where in constrained systems it has to be embraced.
Last year, I ported a commercial remote desktop product to mobile phones. It was written in C++ and ran on Windows, Linux and OSX. But, it relied heavily on STL, dynamic memory and C++ exceptions. To get it going on WinCE, Symbian and OS-less environments a C rewrite was the sanest option.
Any language can be suitable for an embedded system. Embedded just means: part of a larger apparatus, as opposed to a free-to-use computer.
The question has more relevance when asked for a (hard-)real-time or limited-resources system.
For a real-time system C++ is one of the highest languages that is still appropriate when programming for stringent time constraints. With the exception of heap use (free operator) it has no constructs that have an indeterminate execution time, so you can test whether your programm fulfills its timing requirements, and with some more experience you might even predict it. Heap use should of course be avoided, although the new operator can still be used for one-time allocation. The constructs that C++ offers over C can be put to good use in an embedded system: OO, exceptions, templates.
For very resource-limited systems (8-bit chips, less than a few Kb of RAM, no acessible stack) full C++ might be ill-suited, although it might still be used as a 'better C'.
I think it unfortunate that Ada seems to be used only in some niches. In a lot of ways it is a Pascal++, but without the burden of being upwards compatible with a language that was already a serious mess to begin with. (edit: the serious mess is of course C. Pascal is a beautiful but somewhat impractical language.)
================================================================
EDIT: I was typing an answer to new question ( "In which cases is C++ necessary when we are programming microcontrollers"? ) that was closed referring to this one, so I'll add what I wrote:
There is never an all-overruling reason for the use of any programming language, but there can be arguments that have more or less weight in a particular situation. Discussions about this can be found in a lot of places, with positions taken that range from "never use C++ for a micro-controller" to "always use C++". I am more with the last position. I can give some arguments, but you'll have to decide for yourself how much weight they carry in a particular situation (and in which direction).
My blog has some writings on using C++ on small systems (= micro-controllers).
I hope to add more light than heat to this discussion about C++ on bare metal and resource constrained systems.
Problems in C++:
Exceptions are especially a RAM problem as the required "emergency buffer" (where the out of memory exception goes for example) can be larger than the available RAM and is certainly a waste on microcontrollers. For more info see n4049 and n4234. They should be turned off (which is currently unspecified behavior so be sure and not ever throw). SG14 is currently working on better ways of doing this.
RTTI is probably never worth the overhead, it should be turned off
Large debug builds, although this is not a problem in classic desktop development if the debug does not fit on the chip it can be a problem. The problem arises from templated code or extra function calls added for clarity. These extra function calls will be removed again by the optimizer and the added clarity or flexibility can be a great advantage, however in debug builds this can be a problem.
Heap allocation. Although the STL allows for the use of custom allocators this can be complex for most programmers. Heap allocation is non deterministic (i.e. not hard real time) and fragmentation can lead to unexpected out of memory situations to occur despite having worked in testing. The book keeping needed by the heap in order to keep track of free space and varying size can be a problem with small objects. Its usually better to use pool allocation (both in C and C++) but this can be abnormal for C++ programmers used to only using the heap.
Runtime polymorphism and other indirect calls are usually a big performance hit, the problem is usually more because the optimizer cannot see through them more than the actual fetching and jumping to the address. Indirect calls are to be avoided for this reason in C and C++ where as in C++ they are more ingrained in the culture (and are quite useful in other domains).
implicit interfacing with clib can be problematic. It might be counterintuitive that clib problems are in the C++ category but the problem arises from implicit sharing of resources in concurrent environments (sharing is more explicit in C). Use of the common newLib implementation often drags in a lot of bloat which is usually not needed in uCs, on the other hand newLibNanno is not reentrant so access to it must be serialized (oversimplifying here). This is a problem for C as well but the access is more explicit. As a rule of thumb one should essentially use nothing from namespace std in ISR context unless you are sure it does not access state in clib somehow (errorno or the heap for example). Its also important if you are using threads (I prefer RTC) to override new and delete to synchronize access to malloc and free.
In conclusion C++ has some problems but they are essentially all fixable or avoidable.
Now for C, here the problem is higher order. I do not have the syntactic ability in C to abstract things in a way that I can perform optimization or check invariants at compile time. Therefore I cannot properly encapsulate things in a way that the user does not need to know how they work in order to use them and most of my error detection is done at runtime (which is not only too late but also adds cost). Essentially the only way to be generic in C is through data, I pass a format string to printf or scanf which is evaluated at runtime for example. It is then quite hard for the compiler to prove that I am not using some of the options which are theoretically possible when passed the right data which means potential dead code generation and loss of optimization potential.
I know I may be unleashing a shitstorm here but my experience on 32 bit microcontrollers is that in an apples to apples comparison of C and C++ both written by experts (as in C++ potentially highly templated) C++ is the much more efficient language as soon as anything needs to be at all generic (as in any library) and they are essentially equivalent in non generic cases. It is also easier for a novice to leverage the expertise of an expert library implementer in C++.
At the same time there are actually truly few functions to which I cannot pass incorrect data, as soon as the input is not an int but a something for which I happen to be using an int as a method of representation then there is a potential get it wrong (pass an invalid value or an 'otherThing' rather than a 'something'). In C my only method of checking if the user got it wrong is at runtime. In C++ I have the ability to perform some checks, not all checks but some checks at compile time which are free.
At the end of the day a C team is often as powerful as its weakest programmer and the resulting code's benefit has either a multiplayer of 1 or a performance penalty. What I mean by this is it is either high performance for one and only one unique job in a unique environment of unique design decisions or it is generic enough to be used in multiple environments (other microcontroller, other memory management strategy, other latency vs. throughput trade offs etc. etc.) but has an inherent performance cost.
In C++ things can be encapsulated by experts and used in many environments where compile time code generation adapts to the specific task and static checking keeps users from doing stupid stuff at zero cost. Here we have far less trade off between being generic and being fast and thus ultimately from an cost vs. benefit standpoint are the more performant, safer and more productive language.
It is a valid critique that there is still a great shortage of good C++ libraries for embedded, this can lead to pragmatic decisions to use mostly C on a C++ compiler. Decisions to use only C in a project are essentially either ideologically driven, out of need for legacy support or an admission that the team is not disciplined enough to refrain from a very select set of stupid things which one can do in C++ but not in C and at the same time disciplined enough to not do any of the far greater set of stupid things which one cannot guard against in C but could in C++.
My background: just out of school training under old Bell Labs programmers; been working for 3 years, 2 on undergrad research project; data acquisition / process control in VB.NET. Spent 1.5 years doing work on an enterprise database application in VB6. Currently working on project for embedded PC with 2GB of storage, 512MB of RAM, 500MHz x86 CPU; several apps running concurrently written in C++ with an IPC mechanism in between. Yes, I'm young.
My opinion: I think C++ can work effectively given the environment I've written above. Admittedly, hard real-time performance isn't a requirement for the app I'm on, and in some embedded applications, that can be an issue. But here are the things I've learned:
C++ is fundamentally different than C (ie, there is no C/C++). While everything that is valid C is valid C++, C++ is a very different language and one needs to learn how to program in C++, not C, to effectively use it in any situation. In C++, you need to program object-orientedly, not procedurally, and not a hybrid of the two (big classes with lots of functions). In general, you should focus on making small classes with few functions, and compose all the small classes together into a larger solution. One of my coworkers explained to me that I used to program procedurally in objects, which is a grand mess and is hard to maintain. When I started to apply more object-oriented techniques, I found my code's maintainability/readability went up.
C++ provides additional features in the form of object-oriented development that can provide a way to simplify code to make it easier to read/maintain. Honestly, I don't think there's much in the way of a performance/space efficiency improvment in doing OOP. But I think OOP is a technique that can help split up a complex problem into lots of little pieces. And that is helpful for the people working on the code, an element of this process that should not be ignored.
Many arguments against C++ have primarily to do with dynamic memory allocation. C has this same problem too. You can write an object oriented application without using dynamic memory, although one of the benefits of using objects is that you can allocate these things dynamically in an easy fashion. Just as in C, you have to be careful about how manage the data to reduce memory leaks, but the RAII technique makes this simpler in C++ (make dynamic memory destruct automatically by encapsulating it in objects). In some applications, where every memory location counts, this may be too wild & wooly to manage.
EDIT:
Yes, the issue with C++ is the increased footprint of the code.
In some systems you are counting bytes, and in that case you are going to have to accept a cost of running that close to the bounds of your systems are increased development cost of C.
But, even in C, for a well designed system you need to keep everything encapsulated. Well designed systems are hard, and C++ give programmers a place for a very structured and controlled method of development. There is a cost to learn OOP, and if you want to switch to it you much accept it, and in many cases the management would rather continue with C and not pay the cost, as it is hard to measure the results of a switch that increases productivity. You can see an article by embedded systems guru Jack Ganssle here.
Dynamic memory management is the devil. Not really, the devil is auto-route, dynamic memory management works great on a PC, but you can expect to restart a PC every few weeks at least. You will find that as an embedded system continues to run for 5 years that dynamic memory management can really get screwed up and actually start failing. Ganssle discusses things like stack and heap in his article.
There are some things in C++ that are more prone to causing problems and use many resources, removing dynamic memory management and templates are big steps to keep the footprint of C++ closer to the footprint of C. This is still C++, you do not need dynamic memory management or templates to write good C++. I did not realize they removed exceptions, I consider exceptions an important part of my code that I remove in the release, but use until that point. In field testing I can have exceptions generate messages to inform me of an exception being caught.
I thought this anti-C++ rant by Linus Torvalds was interesting.
One of the absolute worst features of C++ is how it makes a lot of things so context-dependent - which just means that when you look at the code, a local view simply seldom gives enough context to know what is going on.
He's not talking about the embedded systems world, but Linux kernel development. To me, the relevance comes from this: C++ requires understanding a larger context, and I can learn to use a set of object templates, I don't trust myself to remember them when I have to update the code in a few months.
(On the other hand, I'm currently working on an embedded device using Python (not C++, but using the same OOP paradigm) that will have exactly that problem. In my defense, it's an embedded system powerful enough to be called a PC 10 years ago.)
I think other answers made a pretty good case for the pros and cons and decision factors, so I'd like just to summarize and add a few comments.
For small microcontrollers (8-bit), no way. You're just asking to hurt yourself, there's no gain and you'll give up too much resources.
For high-end microcontrollers (e.g. 32-bit, 10s or 100s of MB for RAM and storage) that have a decent OS it's perfectly OK and, I'd dare to say, even recommended.
So the question is: where's the boundary?
I don't know for sure, but once I developed a system for a 16-bit uC with 1 MB RAM & 1 MB storage in C++, only to regret it later. Yes, it worked, but the extra work I had wasn't worth it. I had to make it fit, make sure things like exceptions wouldn't produce leaks (the OS+RTL support was pretty buggy and unreliable). Moreover, an OO app typically does lots of small allocations, and the heap overhead for those was another nightmare.
Given that experience, I'd assume for future projects that I'll choose C++ only in systems at least 16-bit, and with at least 16 MB for RAM & storage. That's an arbitrary limit, and probably will vary according to things like the type of application, coding styles and idioms, etc. But given the caveats, I'd recommend a similar approach.
There are some features of C++ which are useful in embedded systems. There are others, like exceptions, which can be expensive, and whose costs may not always be apparent.
If I had my druthers, there would be a popular language which combined the best of both worlds, and included some features which are lacking in both languages; some vendors include a few such features, but there are no standards. A few things I'd like to see:
inline void copy_uint32s(uint32_t *dest, const uint32_t *src, __is_const int n)
{
if (n <= 0) return;
else if (n == 1) {dest[0] = src[0];}
else if (n == 2) {dest[0] = src[0]; dest[1] = src[1];}
else if (n == 3) {dest[0] = src[0]; dest[1] = src[1]; dest[2] = src[2];}
else if (n == 4) {dest[0] = src[0]; dest[1] = src[1]; dest[2] = src[2]; dest[3] = src[3];}
else memcpy((void*)dest, (const void*)src, n*sizeof(*src));
}
If 'n' can be evaluated at compile time, the above code will be more efficient than a call to memcpy, but if 'n' can't be evaluated at compile time the generated code would be much bigger and slower than code which simply called memcpy.
I know the father of C++ isn't too keen on an embedded-only version of C++, but I would think it could offer some considerable improvements over just using C.
Anyone know if anything like the above are being considered for any type of standard?
C++ is more that one programming language:
a) It's a "better" C b) It's an object oriented language c) It's a language that allows us to write generic programs
Although all of these features can be used separately the best results are achieved when the three of them are used at the same time. Nonetheless, if you choose to pick just one of them the quality of the embedded software will increase.
a) It's a "better" C
C++ is a strong typed language; stronger than C. Your programs will benefit from this feature.
Some people is afraid of pointers. C++ includes the references. Overloaded functions.
And worth to say: None of these features incurred in bigger or slower programs.
b) It's an object oriented language
Someone said in this post that abstracting the machine in microcontrollers is not a good idea. Wrong! All of us, the embedded engineers, have always abstracted the machine, just with other sintax that that of C++. The problem I see with this argument is that some programmers are not used to think in objects, that's way they don't see the benefits of OOP.
Whenever you are ready to use a microcontroller's peripheral it's likely that the peripheral has been abstracted for us (from yourself or a third party) in the form of the device driver. As I said before, that driver uses the C sintax, as the next example shows (taken directly from a NXP LPC1114 example):
/* Timer setup for match and interrupt at TICKRATE_HZ */
Chip_TIMER_Reset(LPC_TIMER32_0);
Chip_TIMER_MatchEnableInt(LPC_TIMER32_0, 1);
Chip_TIMER_SetMatch(LPC_TIMER32_0, 1, (timerFreq / TICKRATE_HZ2));
Chip_TIMER_ResetOnMatchEnable(LPC_TIMER32_0, 1);
Chip_TIMER_Enable(LPC_TIMER32_0);
Do you see the abstraction? So, when using C++ for the same purpose, abstraction is brought to the next level through abstraction and encapsulation mechanism of C++, at zero cost!
c) It's a language that allows us to write generic programs
Generic programs are achieved through templates, and templates also have no costs for our programs.
Besides, static polymorphism is achieved with templates.
Virtual methods, RTTI and exceptions.
There is a compromise when using virtual methods: better software vs some penalty in performance. However, remember that dynamic binding is likely to be implemented using a virtual table (an array of function pointers). I have done the same in C a lot of times (even in a regular basis), so I don't see the drawbacks in using virtual methods. Moreover, virtual methods in C++ are more elegant.
Finally, an advice about RTTI and exceptions: DON'T USE THEM in embedded systems. Avoid them at all cost!!
My background, embedded (mcu, pc, unix, other), realtime. Safety critical. I introduced a previous employer to STL. I don't do that anymore.
Some Flame content
Is C++ suitable for embedded systems?
Meh. C++ is a pain to write and a pain to maintain. C+ is sort-of okay ( don't use some features)
C++ in Microcontrollers? RTOSes? Toasters? Embedded PCs?
Again I say Meh. C+ is not too bad, but ADA is less painful (and that's really saying something) . If you're lucky like me, you get to do embedded Java. Checked array access and no pointer arithmetic makes for very reliable code. Garbage collectors in embedded Java are not highest priority, and there is scoped memory and object reuse, so well designed code can run forever without a GC.
Is OOP useful on microcontrollers?
Sure is. The UART is an object..... The DMAC is an object...
Object State machines are very easy.
Does C++ remove the programmer too far from the hardware to be efficient?
Unless it's a PDP-11, C ain't your CPU. C++ was originally a preprocessor ontop of C so Bjarne Stroustrup would stop getting laughed at for having slow Simula simulations while at AT&T. C++ ain't your CPU.
Go get an MCU that runs java bytecodes. Program in Java. Laugh at the C guys.
Should Arduino's C++ (with no dynamic memory management, templates, exceptions) be considered as "real C++"?
Nope. just like all the bastardised C compilers out there for MCU's.
Forth, Embedded Java or Embedded ADA are standardised(ish); all else is sorrow.
<rant>
I think C++ is a crappy language in the first place. If you want to use OOP, write Java programs. C++ does nothing to enforce OOP paradigms, as direct memory access is fully within your power to (ab)use.
If you have an MCU, you're talking about most likely less than 100kB of flash memory. You want to be programming in a language whose abstraction of memory is: when I declare a variable or an array, it gets memory, period; malloc (aka "new" keyword in C++) should be more or less banned from use in embedded software, except perhaps in rare occasions one call during program startup.
Hell, there are (frequently) times in embedded programming where C is not quite low-level enough, and you need to do things like allocate variables to registers, and write inline assembly to tighten up your interrupt service routines (ISRs). Keywords like "volatile" become pretty darn important to understand. You spend a lot of your time manipulating memory at the bit level, not the object level.
Why would you want to delude yourself into thinking that things are simpler than they in fact are?
</rant>
Embedded systems are designed to do some specific task, rather than be a general-purpose computer for multiple tasks. An embedded system is a combination of computer hardware and software. C is the mother of all the modern languages. It’s a low level but power full language and deals all kind of hardware. So C/C++ is an optimal choice for developing software for embedded system, which is very use full for every embedded system .As we know C is a developing language. The operating system UNIX is written in C .Because successful software development is so frequently about selecting the best language for a given project, it is surprising to find that C/C++ language has proven itself appropriate for both 8-bit and 64-bit processors; in systems with bytes, kilobytes, and megabytes of memory. C has the benefit of processor-independence, which allows programmers to concentrate on algorithms and applications, rather than on the details of particular processor architecture. However, many of these advantages apply equally to other high-level languages. But C/C++ succeeded where so many other languages have largely failed?