Return to Answer

• C++ compilers are more rare than C compilers; for some targets (for instance 12 and 14 bit core PICs) there are no C++ compilers at all.
• (good) C++ programmers are more rare than (good) C programmers, especially among those that are also (somewhat) knowledgeable in electronics.
• C++ has more constructs than C that are not appropriate for small systems (like exceptions, RTTI, frequent use of the heap).
• C++ has a richer set of (standard) libraries than C, but a consequence of the previous point is that C++ libraries often use features that are inappropriate for small systems and are hence not uasble on small systems.
• C++ has more constructs than C that allow you to shoot yourself in the foot.
• C++ has more constructs than C that allow you to prevent yourself from shooting yourself in the foot (yes, IMO this and the previous one are both true).
• C++ has a richer set of abstraction mechanisms, so it enables better ways of programming, especially for libraries.
• C++ language features (for instance constructors/destructors, conversion functions) make it more difficult to see through the code to see the generated machine and thus the cost in space and time of a language construct.
• C++ language construct make it less necessary to be aware of how exactly the are translated to machine code because they do 'the right thing' in a more abstract way.
• The C++ language standard is evolving quickly and is adopted speedily by the big compilers (gcc, clang, microsoft). C is evolving rather sowly, and adoption of some newer features (variant arrays) is scare and has even been reverted in a later standard. This point in particular is interesting in that different people use it to support the opposite positions.
• C++ is undoubtedly a sharper tool than C. Do you trust your programmers (or yourself) to use such a tool to make a beautiful sculpture, or do you fear them hurting themselves and would you rather settle for a less beautiful but lower-risk product?

• C++ compilers are more rare than C compilers; for some targets (for instance 12 and 14 bit core PICs) there are no C++ compilers at all.
• (good) C++ programmers are more rare than (good) C programmers, especially among those that are also (somewhat) knowledgeable in electronics.
• C++ has more constructs than C that are not appropriate for small systems (like exceptions, RTTI, frequent use of the heap).
• C++ has a richer set of (standard) libraries than C, but a consequence of the previous point is that C++ libraries often use features that are inappropriate for small systems and are hence not uasble on small systems.
• C++ has more constructs than C that allow you to shoot yourself in the foot.
• C++ has more constructs than C that allow you to prevent yourself from shooting yourself in the foot (yes, IMO this and the previous one are both true).
• C++ has a richer set of abstraction mechanisms, so it enables better ways of programming, especially for libraries.
• C++ language features (for instance constructors/destructors, conversion functions) make it more difficult to see through the code to see the generated machine and thus the cost in space and time of a language construct.
• C++ language construct make it less necessary to be aware of how exactly the are translated to machine code because they do 'the right thing' in a more abstract way.
• The C++ language standard is evolving quickly and is adopted speedily by the big compilers (gcc, clang, microsoft). C is evolving rather sowly, and adoption of some newer features (variant arrays) is scare and has even been reverted in a later standard. This point in particular is interesting in that different people use it to support the opposite positions.
• C++ is undoubtedly a sharper tool than C. Do you trust your programmers (or yourself) to use such a tool to make a beautiful sculpture, or do you fear them hurting themselves and would you rather settle for a less beautiful but lower-risk product? (I recall that my sculpture teacher once told me that blunt tools can in some situations be more dangerous than sharp ones.)

================================================================

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).

• C++ compilers are more rare than C compilers; for some targets (for instance 12 and 14 bit core PICs) there are no C++ compilers at all.
• (good) C++ programmers are more rare than (good) C programmers, especially among those that are also (somewhat) knowledgeable in electronics.
• C++ has more constructs than C that are not appropriate for small systems (like exceptions, RTTI, frequent use of the heap).
• C++ has a richer set of (standard) libraries than C, but a consequence of the previous point is that C++ libraries often use features that are inappropriate for small systems and are hence not uasble on small systems.
• C++ has more constructs than C that allow you to shoot yourself in the foot.
• C++ has more constructs than C that allow you to prevent yourself from shooting yourself in the foot (yes, IMO this and the previous one are both true).
• C++ has a richer set of abstraction mechanisms, so it enables better ways of programming, especially for libraries.
• C++ language features (for instance constructors/destructors, conversion functions) make it more difficult to see through the code to see the generated machine and thus the cost in space and time of a language construct.
• C++ language construct make it less necessary to be aware of how exactly the are translated to machine code because they do 'the right thing' in a more abstract way.
• The C++ language standard is evolving quickly and is adopted speedily by the big compilers (gcc, clang, microsoft). C is evolving rather sowly, and adoption of some newer features (variant arrays) is scare and has even been reverted in a later standard. This point in particular is interesting in that different people use it to support the opposite positions.
• C++ is undoubtedly a sharper tool than C. Do you trust your programmers (or yourself) to use such a tool to make a beautiful sculpture, or do you fear them hurting themselves and would you rather settle for a less beautiful but lower-risk product?

My blog has some writings on using C++ on small systems (= micro-controllers).

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.

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.)