Bug in compiler

I don't know how much that might "cramp your style"

I'll get my own bias out of the way first: "Embedded C++" was really a political move. It was created by (in my opinion) a bunch of lazy compiler vendors. C++ is a *** to compile at all, much less do a good job. And a lot of people simply didn't want to try. So, "Embedded C++" is really more about excluding newer and/or more difficult to compile features, rather than any real concern over "efficiency" or appropriateness for embedded programming. (Modern C++ compilers efficiently implement just about all of the features EC++ excludes.) That's just the excuse by which the limitation was sold.

Besides, even if feature X were harmful in embedded programming, you could simply not use it. (Compare with, say, bitfields in regular C -- widely regarded as not worth the effort and unused. That doesn't mean we need an "Embedded C" standard officially excluding it to give the marketing guys an excuse...)

On to details, from the IAR website, though I've inserted numbers for reference:

Embedded C++ lacks the following features of C++:

1) Templates
2) Multiple inheritance
3) Exception handling
4) Runtime type information
5) New cast syntax (operators dynamic_cast, static_cast, reinterpret_cast, and const_cast)
6) Namespaces

7) The Standard Template Library (STL) is excluded
8) Streams, strings, and complex numbers are supported without the use of templates
9) Library features which relate to exception handling and runtime type information (headers <except>, <stdexcept> and <typeinfo>), are excluded

(1), which implies (7), is critically limited to a "real C++" programmer. There's nothing inherently bad about templates. Poor use of them can bloat your code. But then, poor use of #defines can bloat your code, for much the same reason. That's a problem with the programmer, not the language feature.

(2) exists for a very specific reason in the real world. If you're an academic OO purist and you always have full source for every scrap of your project, you sneer at MI. If, on the other hand, you ever use a commercial library as well as writing your own code, you're often faced with the problem of inheriting from two separate trees of objects. MI is the onlly answer. It's also quite useful in some specific idioms, such as the mixin or the "abstract base class" -- what Java calls an "interfere" and which they added back in after their single-inheritance OO purity proved impractical.

(3) Pretty darn useful in an embedded system to make sure everything gets cleaned up with things go wrong. A robust system in EC++ is just going to have to reinvent this wheel from scratch, and won't have the power of a language feature. Early implementations could be bloated and slow, but compiler vendors learned how to implement it and programmers learned proper idioms like RAII for its use.

(5) Pure bias against new features as far as I can tell. If you do away with RTTI, then dynamic_cast does you no good. But the other three are just the three uses of traditional C casts, and there's no reason from the compiler vendor's point of view that they're hard to support. The only difference is that the syntax makes the programmer's intent obvious, where "(typename)" is sometimes too powerful for your own good. Like I said, lazy compiler vendors.

(6) An incredibly useful feature for anything more than the simplest program. One of the biggest gripes about C was always its lack of depth in structure: you're either static and hidden, or public and completely global. Hence the development of coding tics like always putting Module Code Abbreviations in mca_MyFunc() to try to avoid clashes in the global namespace, and conventions about _symbol and __symbol to hide stuff needed in your libraries. Those are just a poor man's attempt to create namespaces that clutters the code because they don't have proper language support. Again, the feature is not at all hard to implement, but it was newfangled at the time and the lazy compiler vendors strike again. They didn't already have it working at the time they defined the EC++ spec, out it went, baby and bathwater alike.

(8) OMG! A feature you can actually argue is not terribly useful in the majority of embedded work. But then, it also falls squarely under Stroustrup's "don't pay for what you don't use" principle. If you don't use the complex type or a string, why then, you won't link in any of libraries, would you? Wouldn't cost a thing for people that didn't need it. (Did I mention I find the EC++ backers extremely lazy?)

I don't know how much that might "cramp your style"

I'll get my own bias out of the way first: "Embedded C++" was really a political move. It was created by (in my opinion) a bunch of lazy compiler vendors. C++ is a *** to compile at all, much less do a good job. And a lot of people simply didn't want to try. So, "Embedded C++" is really more about excluding newer and/or more difficult to compile features, rather than any real concern over "efficiency" or appropriateness for embedded programming. (Modern C++ compilers efficiently implement just about all of the features EC++ excludes.) That's just the excuse by which the limitation was sold.

Besides, even if feature X were harmful in embedded programming, you could simply not use it. (Compare with, say, bitfields in regular C -- widely regarded as not worth the effort and unused. That doesn't mean we need an "Embedded C" standard officially excluding it to give the marketing guys an excuse...)

On to details, from the IAR website, though I've inserted numbers for reference:

Embedded C++ lacks the following features of C++:

1) Templates
2) Multiple inheritance
3) Exception handling
4) Runtime type information
5) New cast syntax (operators dynamic_cast, static_cast, reinterpret_cast, and const_cast)
6) Namespaces

7) The Standard Template Library (STL) is excluded
8) Streams, strings, and complex numbers are supported without the use of templates
9) Library features which relate to exception handling and runtime type information (headers <except>, <stdexcept> and <typeinfo>), are excluded

(1), which implies (7), is critically limited to a "real C++" programmer. There's nothing inherently bad about templates. Poor use of them can bloat your code. But then, poor use of #defines can bloat your code, for much the same reason. That's a problem with the programmer, not the language feature.

(2) exists for a very specific reason in the real world. If you're an academic OO purist and you always have full source for every scrap of your project, you sneer at MI. If, on the other hand, you ever use a commercial library as well as writing your own code, you're often faced with the problem of inheriting from two separate trees of objects. MI is the onlly answer. It's also quite useful in some specific idioms, such as the mixin or the "abstract base class" -- what Java calls an "interfere" and which they added back in after their single-inheritance OO purity proved impractical.

(3) Pretty darn useful in an embedded system to make sure everything gets cleaned up with things go wrong. A robust system in EC++ is just going to have to reinvent this wheel from scratch, and won't have the power of a language feature. Early implementations could be bloated and slow, but compiler vendors learned how to implement it and programmers learned proper idioms like RAII for its use.

(5) Pure bias against new features as far as I can tell. If you do away with RTTI, then dynamic_cast does you no good. But the other three are just the three uses of traditional C casts, and there's no reason from the compiler vendor's point of view that they're hard to support. The only difference is that the syntax makes the programmer's intent obvious, where "(typename)" is sometimes too powerful for your own good. Like I said, lazy compiler vendors.

(6) An incredibly useful feature for anything more than the simplest program. One of the biggest gripes about C was always its lack of depth in structure: you're either static and hidden, or public and completely global. Hence the development of coding tics like always putting Module Code Abbreviations in mca_MyFunc() to try to avoid clashes in the global namespace, and conventions about _symbol and __symbol to hide stuff needed in your libraries. Those are just a poor man's attempt to create namespaces that clutters the code because they don't have proper language support. Again, the feature is not at all hard to implement, but it was newfangled at the time and the lazy compiler vendors strike again. They didn't already have it working at the time they defined the EC++ spec, out it went, baby and bathwater alike.

(8) OMG! A feature you can actually argue is not terribly useful in the majority of embedded work. But then, it also falls squarely under Stroustrup's "don't pay for what you don't use" principle. If you don't use the complex type or a string, why then, you won't link in any of libraries, would you? Wouldn't cost a thing for people that didn't need it. (Did I mention I find the EC++ backers extremely lazy?)