我读了一些关于以前尝试为嵌入式平台制定C++标准的问题，他们专门声明多重继承是坏的，因此不被支持。据我所知，这从来没有被实现为主流，大多数嵌入式C++编译器都支持大多数标准的C++构造。嵌入式C++编译器不支持多继承的实例？
是否存在当前嵌入式平台上的编译器（即不超过几年之久）绝对不支持多继承的情况？
我真的不想做多重继承，因为我有一个孩子，有两个完整的类的实现。我最感兴趣的是继承一个类的单个实现，然后继承一个或多个纯虚拟类作为接口。这大致相当于Java/.Net，我可以只扩展一个类，但实现尽可能多的接口。在C++中，这些都是通过多重继承完成的，而不是专门定义一个接口并声明一个类实现它。
更新：
我不感兴趣，即使是或不是技术上C++，它是如何试图哑下来C++ C程序员应付，产生较小的二进制文件，或任何宗教人们正在用这个话题来进行激烈的战争。我想知道是否有目前的嵌入式平台，为了开发的目的，提供它们自己的不支持多重继承的C++编译器（即我不能使用GCC或MSVC）。我提到嵌入式C++标准的目的仅仅是给出背景。
在EC++子集中施加的许多限制都是为了允许在小型16位和32位目标的广泛编译器支持，而并非所有C++编译器都支持所有新兴功能（例如，GCC在版本3之前不支持命名空间.x和EC++省略名称空间支持）。这是在ISO C++标准化之前，任何类型的标准化对许多嵌入式项目都很重要。所以它的目标是促进在嵌入式系统之前采用C++之前必要的标准化已经到位。
然而，它的时间已经过去了，这在很大程度上是无关紧要的。关于C++的“昂贵”和“非确定性”元素有几点需要说明，这些元素仍然相关，但其中很大一部分是针对兼容性的。
请注意，EC++是C++的真正子集，并且任何EC++程序也是有效的C++程序。事实上，它仅仅是根据它省略的而不是完整的语言定义来定义的。 Green Hills，IAR和Keil都生产带有开关的编译器来强制执行EC++子集，但由于它主要是可移植性的问题，因为所有这些编译器都支持ISO C++，所以完全没有意义。在大多数情况下，您可能想遵守的EC++规范的那些部分可以简单地通过在全功能编译器上不使用这些功能来实现。
有非常严格的系统的C++编译器，它们既不完全是ISO C++也不是EC++。
如果它不支持MI，那么它不是C++。
确实如此，但它可能仍然是一个真正的*子集*，因此这种语言中的代码也是有效的C++。这就是EC++的。 – Clifford 2010-05-29 20:18:32
如果您指的是“嵌入式C++”，那么我还不知道任何商业实现的运送。坦率地说，如果你看看项目的目标，这只是C++的一个缺陷，就像Barber先生指出的那样，它不能被认为是C++。
他们的意图很好，但在我看来被误导了。他们的关键驱动力是让C程序员更容易并消除膨胀。我只是看不到这一点。无论如何，C程序员不会知道使用缺失的功能。与具有相同代码的C++编译器相比，“嵌入式C++”编译器不会产生更小或更严格的代码。
好的尝试，我熟悉那些论点。 – Nathan 2010-05-28 21:40:22
我想知道是否有当前嵌入式平台，对于开发目的，提供自己的C++编译器（即我不能使用GCC或MSVC）不支持多重继承
没有，不是我所知道的。任何认为MI不好的嵌入式平台可能只是认为OOP的开销总体上不好，并且不会提供任何过去的C。
我从未见过一个。我见过嵌入式C++编译器，它们省略了异常，流，甚至嵌套深度超过N，但没有一个抛出多重继承。我无法真正了解多重继承如何成为特定的空间或速度问题，或者至少比虚拟功能更普遍。
对不起，我老的答案，但令人难以置信的还是有关截至2014年发布的：
苹果OS X，XNU内核编译内核级的I/O Kit的驱动程序（libkern的）不支持多重继承。
从Mac开发库：
的I/O Kit的是建立在libkern的C++库，它是用C++编写适用于可装载内核模块的子集的顶部。具体来说，libkern C++环境不支持多继承，模板，C++异常处理工具和运行时类型信息（RTTI）。 C++ RTTI工具被忽略，因为它不支持通过名称动态分配类，这是加载内核扩展所需的功能。 RTTI也大量使用例外。但是，libkern C++环境定义了自己的运行时类型系统，它支持动态加载。
由于成本和稳定性的原因，在内核中禁止例外。它们增加了代码的大小，从而消耗了宝贵的内核内存，并引入了不可预知的延迟。此外，由于许多客户端线程可能会调用I/O Kit代码，因此无法保证会发生异常。不支持在任何内核扩展中使用try，throw或catch，并会导致编译错误。虽然不能在I/O Kit驱动程序中使用异常，但驱动程序应始终在适当的地方检查返回代码。
苹果公司强烈建议您在所有核心级C++代码，包括设备驱动程序，在libkern的基类，即OSObject和OSMetaClass类，并遵守那些类
所以是所规定的规则，它是仍然在真实系统上的生产环境。不是很多，但它存在。当你编写未完成的硬件时更常见，因为编译器的端口也可能未完成。作为编写大量底层框架的人，我完全期望在今年能够使用C11 ......从来没有。 Yargh。
您阅读关于EC++？我认为它仍然不被支持 – Nikko 2010-05-28 14:20:00
或者，对于纯粹的，哪些平台没有C++编译器，但是确实有一个用于类似C语言的C++语言，它具有许多C++特性包括MI。 –
2010-05-28 21:45:55
与您的问题相关，但不是对您的问题的回答：一个C++编译器我使用目标ARM为Thumb指令集编译时产生了错误代码（来自不同基类的虚函数的thunk具有'松弛空间'，应该初始化为没有操作说明，但有时充满垃圾）。问题已经解决，但当时它给我们造成了相当多的痛苦。我的观点是，即使编译器支持MI，该功能在较小的系统上也没有太多用处，所以你应该明智地测试它。 – 2010-05-28 23:10:23