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

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 do开发者_如何学Gown 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.

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.

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

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

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.

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.

Sorry for the old answer, but unbelievably still relevant as of 2014 release:

Apple OS X, XNU Kernel Compiler kernel-level I/O Kit drivers (libkern) does not support multiple inheritance.

From the Mac Developer Library:

The I/O Kit is built on top of the libkern C++ library, which is written in a subset of C++ suitable for use in loadable kernel modules. Specifically, the libkern C++ environment does not support multiple inheritance, templates, the C++ exception-handling facility, and runtime type information (RTTI). The C++ RTTI facility is omitted because it doesn’t support dynamic allocation of classes by name, a feature required for loading kernel extensions. RTTI also makes considerable use of exceptions. However, the libkern C++ environment defines its own runtime typing system, which does support dynamic loading.

Exceptions are forbidden in the kernel for reasons of both cost and stability. They increase the size of the code, thereby consuming precious kernel memory, and introduce unpredictable latencies. Further, because I/O Kit code may be invoked by many client threads, there’s no way to guarantee that an exception will be caught. Using try, throw, or catch in any kernel extension is not supported and will result in a compilation error. Although you can’t use exceptions in an I/O Kit driver, your driver should always check return codes where appropriate.

Apple highly recommends that you base all kernel C++ code, including that for device drivers, on the libkern base classes, OSObject and OSMetaClass, and observe the conventions prescribed by those classes

So yeah, it's still out there in production environments on real systems. Not a lot, but it exists. It's more often when you're coding for unfinished hardware because the port of the compiler may be unfinished too.

As someone who writes a lot of low-level frameworks, I fully expect I'll get to use C11 in the year... never. Yargh.