嵌入式C ++编译器不支持多重继承的实例？

Question

我读了一些关于之前为嵌入式平台制定C ++标准的尝试，他们特别指出多重继承是坏的，因此不受支持。据我所知，这从未被实现为主流，大多数嵌入式C ++编译器都支持大多数标准C ++构造。

是否存在当前嵌入式平台上的编译器（即不超过几年的东西）绝对不支持多重继承的情况？

在我有一个有两个完整类实现的孩子的意义上，我真的不想做多重继承。我最感兴趣的是继承一个类的单个实现，然后继承一个或多个纯虚拟类作为接口。这大致相当于Java / .Net，我只能扩展一个类，但实现了我需要的尽可能多的接口。在C ++中，这都是通过多重继承完成的，而不是能够专门定义接口并声明一个类实现它。

更新

我不感兴趣，不管它是否是技术上的C ++，它是如何试图愚蠢的C ++程序员应对，生成更小的二进制文件，或者人们用来制造火焰战争的任何宗教话题。

我的观点是：我想知道是否有当前的嵌入式平台，为了开发目的，提供不支持多重继承的自己的C ++编译器（即我不能使用GCC或MSVC）。我提到嵌入式C ++标准的目的只是提供问题的背景知识。

Answer 1

如果您指的是“嵌入式C ++”，那么我不知道还有任何商业实施。坦率地说，如果你看一下这个项目的目标，那就像C ++的失败一样，就像巴伯先生指出的那样，它不能真正被认为是C ++。

他的意图很好，但我认为是错误的。他们的关键驱动因素是让C程序员更容易并消除膨胀。我只是没有看到这一点。无论如何，C程序员都不会知道使用缺失的功能。 “嵌入式C ++”编译器不会生成比具有相同代码的C ++编译器更小或更严格的代码。

Answer 2

如果它不支持MI，那么它不是C ++。

Answer 3

EC ++子集中的许多限制是为了在不是所有C ++编译器都支持所有新兴功能的情况下允许对小型16位和32位目标的广泛编译器支持（例如GCC在版本3之前不支持命名空间。 x，EC ++省略名称空间支持）。这是在ISO C ++标准化之前，任何类型的标准化对许多嵌入式项目都很重要。因此，它的目标是在之前推动在嵌入式系统中采用C ++，以实现必要的标准化。

然而它的时间已经过去了，而且它基本上是无关紧要的。关于C ++的“昂贵”和“非确定性”元素还有一些说法仍然相关，但其中大部分都是针对兼容性的。

请注意，EC ++是C ++的真正子集，任何EC ++程序也都是有效的C ++程序。事实上，它只是根据它省略的内容而不是完整的语言定义来定义。

Green Hills，IAR和Keil都使用交换机生成编译器以强制执行EC ++子集，但由于它主要是可移植性问题，因此所有这些编译器也支持ISO C ++，这完全没有意义。在大多数情况下，您可能希望遵守EC ++规范的那些部分，只需在全功能编译器上不使用这些功能即可。

对于非常受限制的系统，有C ++编译器既不完全是ISO C ++，也不是EC ++。

Answer 4

我想知道是否有当前的嵌入式平台，为了开发目的，提供不支持多重继承的自己的C ++编译器（即我不能使用GCC或MSVC）

不，不是我知道的。任何认为MI都不好的嵌入式平台可能只是认为OOP的开销一般很糟糕，并且不会提供任何超过C的东西。

Answer 5

我从未见过一个人。我已经看到嵌入式C ++编译器省略了异常，流，甚至嵌套了比 N 更深的模板，但没有一个抛出多重继承。我无法真正看到多重继承是一个特定的空间或速度问题，或者至少比虚函数更多。

Answer 6

对于旧答案感到抱歉，但截至2014年发布时仍然令人难以置信地相关：

Apple OS X，XNU内核编译器内核级I / O Kit驱动程序（libkern）不支持多重继承。

来自Mac Developer Library：

  

I / O Kit建立在libkern C ++库的基础之上，该库是用适合在可加载内核模块中使用的C ++子集编写的。具体来说，libkern C ++环境不支持多继承，模板，C ++异常处理工具和运行时类型信息（RTTI）。省略了C ++ RTTI工具，因为它不支持按名称动态分配类，这是加载内核扩展所需的功能。 RTTI也大量使用异常。但是，libkern C ++环境定义了自己的运行时类型系统，它支持动态加载。

     

由于成本和稳定性的原因，内核中禁止例外。它们增加了代码的大小，从而消耗了宝贵的内核内存，并引入了不可预测的延迟。此外，由于许多客户端线程可能会调用I / O Kit代码，因此无法保证将捕获异常。不支持在任何内核扩展中使用try，throw或catch，这将导致编译错误。虽然您不能在I / O Kit驱动程序中使用异常，但驱动程序应始终在适当的位置检查返回代码。

     

Apple强烈建议您将所有内核C ++代码（包括设备驱动程序代码）基于libkern基类，OSObject和OSMetaClass，并遵守这些类规定的约定

所以是的，在实际系统的生产环境中， 仍然 。不是很多，但它存在。当您编写未完成的硬件时，更常见的是，因为编译器的端口也可能未完成。

作为编写大量低级框架的人，我完全相信我会在一年中使用C11 ......永远不会。 Yargh。