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

Question

我读到了一些关于以前为嵌入式平台制定C++标准的尝试，他们明确表示多重继承是不好的，因此不支持。据我所知，这从未作为主流实现，而且大多数嵌入式C++编译器都支持大多数标准的C++结构。

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

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

更新：

我不感兴趣的是它在技术上是否是C++，它是如何让C程序员降低C++的能力，生成更小的二进制文件，或者是人们用来发动火焰战争的任何宗教话题。

我的观点是:我想知道，是否有当前的嵌入式平台，为了开发目的，提供自己的C++编译器(我不能使用GCC或MSVC)，不支持多重继承。我提到嵌入式C++标准的目的仅仅是给出这个问题的背景。

Answer 1

EC++子集中施加的许多限制是为了允许广泛的编译器支持小型16位和32位目标，而不是所有的C++编译器都支持所有新出现的特性(例如GCC直到3.x版本才支持名称空间，EC++省略了名称空间支持)。这是在ISO C++标准化之前，任何类型的标准化对于许多嵌入式项目都很重要。因此，它的目的是在必要的标准化实施之前，促进嵌入式系统中采用C++。

然而，它的时间已经过去，这在很大程度上是无关紧要的。对于C++的“昂贵”和“非确定性”元素，它有几点要说，这些元素仍然是相关的，但其中大部分都是为了兼容性。

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

Green Hills、IAR和Keil都会生成带有开关的编译器来执行EC++子集，但是由于这在很大程度上是一个可移植性的问题，所以这是完全没有意义的，因为所有这些编译器都支持C++。在大多数情况下，您可能想要遵守的EC++规范的那些部分，只需在功能齐全的编译器上不使用这些特性就可以做到。

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

Answer 2

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

在我看来，他们的意图是正确的，但却是错误的。他们的主要驱动因素是使C程序员更容易，并消除臃肿。我只是不明白重点。不管怎么说，程序员都不知道如何使用缺少的特性。“嵌入式C++”编译器不会产生比具有相同代码的C++编译器更小或更紧的代码。

Answer 3

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