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