Instance where embedded C++ compilers don't support multiple inheritance?

Question

I read a bit about a previous attempt to make a C++ standard for embedded platforms where they specifically said multiple inheritance was bad and thus not supported. From what I understand, this was never implemented as a mainstream thing and most embedded C++ compilers support most standard C++ constructs.

Are there cases where a compiler on a current embedded platform (i.e. something not more than a few years old) absolutely does not support multiple inheritance?

I don't really want to do multiple inheritance in a sense where I have a child with two full implementations of a class. What I am most interested in is inheriting from a single implementation of a class and then also inheriting one or more pure virtual classes as interfaces only. This is roughly equivalent to Java/.Net where I can extend only one class but implement as many interfaces as I need. In C++ this is all done through multiple inheritance rather than being able to specifically define an interface and declare a class implements it.

Update:

I'm not interested in if it is or isn't technically C++, how it was an attempt to dumb down C++ for C programmers to cope, generate smaller binaries, or whatever religious topic people are using to wage flame wars.

My point is: I want to know if there are current embedded platforms that, for development purposes, supply their own C++ compiler (i.e. I can't use GCC or MSVC) that does NOT support multiple inheritance. My purpose in mentioning the embedded C++ standard was to give background on the question only.

Answer 1

If it doesn't support MI, then it isn't C++.

Answer 2

If you are referring to "Embedded C++" then I don't know of any commercial implementations shipping yet. Frankly, if you take a look at the project's objectives, it is just a defeaturing of C++ to the point where, like Mr. Barber points out, it can't really be considered C++.

Their intentions are well placed but misguided in my view. Their key drivers are to make it easier for C programmers and remove the bloat. I just don't see the point. C programmers wouldn't know to use the missing features anyway. An "Embedded C++" compiler won't produce smaller or tighter code than a C++ compiler with the same code.

Answer 3

I want to know if there are current embedded platforms that, for development purposes, supply their own C++ compiler (i.e. I can't use GCC or MSVC) that does NOT support multiple inheritance

No, not that I'm aware of. Any embedded platform that thought MI was bad probably just thinks the overhead of OOP is bad in general and wouldn't supply anything past C.

Answer 4

I've never seen one. I've seen embedded C++ compilers that omitted exceptions, streams, and even templates nested more than N deep, but none that threw out multiple inheritance. I can't really see how multiple inheritance would be a particular space or speed issue, or at least more so than virtual functions generally.

Answer 5

Many of the restrictions imposed in the EC++ subset were made to allow wide compiler support for small 16 and 32 bit targets at a time when not all C++ compilers supported all emerging features (for example GCC did not support namespaces until version 3.x, and EC++ omits namespace support). This was before ISO C++ standardisation, and standardisation of any kind is important to many embedded projects. So its aim was to promote adoption of C++ in embedded systems before the necessary standardisation was in place.

However its time has passed, and it is largely irrelevant. It has a few things to say about 'expensive' and 'non-deterministic' elements of C++ which are still relevant, but much of it was aimed at compatibility.

Note that EC++ is a true subset of C++, and that any EC++ program is also a valid C++ program. In fact it is defined solely in terms of what it omits rather than a complete language definition.

Green Hills, IAR, and Keil all produce compilers with switches to enforce the EC++ subset, but since it is largely a matter of portability, it is entirely pointless since all these compilers also support ISO C++. For the most part those parts of the EC++ specification you might want to adhere to you can do so simply by not using those features on a fully featured compiler.

There are C++ compilers for very restricted systems that are neither fully ISO C++ nor EC++.