嵌入 C++ 的实例编译器不支持多重继承？
我读到了一些关于之前为嵌入式平台制定 C++ 标准的尝试，其中他们特别指出多重继承是不好的，因此不支持。据我了解，这从未作为主流实现，并且大多数嵌入式 C++ 编译器支持大多数标准 C++ 结构。
是否存在当前嵌入式平台（即不超过几年的平台）上的编译器绝对不支持多重继承的情况？
从某种意义上说，我真的不想进行多重继承，因为我的孩子有一个类的两个完整实现。我最感兴趣的是从类的单个实现继承，然后仅将一个或多个纯虚拟类作为接口继承。这大致相当于 Java/.Net，其中我只能扩展一个类，但可以实现所需数量的接口。在 C++ 中，这一切都是通过多重继承来完成的，而不是能够专门定义一个接口并声明一个类来实现它。
更新：
我不感兴趣它在技术上是否是 C++，它是如何试图简化 C++ 以便 C 程序员应对、生成更小的二进制文件，或者人们所关心的任何宗教主题用于发动口水战。
我的观点是：我想知道当前是否存在出于开发目的而提供自己的不支持多重继承的 C++ 编译器（即我不能使用 GCC 或 MSVC）的嵌入式平台。我提及嵌入式 C++ 标准的目的只是为了提供该问题的背景。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果您指的是“嵌入式 C++”，那么我还不知道有任何商业实现。坦率地说，如果你看一下该项目的目标，它只是对 C++ 的挫败，以至于像 Barber 先生指出的那样，它不能真正被视为 C++。
他们的意图是好的，但在我看来是误导的。它们的关键驱动力是让 C 程序员更容易并消除臃肿。我只是不明白这一点。无论如何，C 程序员都不知道如何使用缺失的功能。 “嵌入式 C++”编译器不会生成比具有相同代码的 C++ 编译器更小或更紧凑的代码。
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.
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++。
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++.
如果它不支持 MI，那么它就不是 C++。
If it doesn't support MI, then it isn't C++.
我想知道当前是否存在出于开发目的而提供自己的不支持多重继承的 C++ 编译器（即我不能使用 GCC 或 MSVC）的嵌入式平台
不，不是我我知道。任何认为 MI 不好的嵌入式平台可能只是认为 OOP 的开销总体来说不好，并且不会提供超越 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.
我从来没有见过一个。我见过嵌入式 C++ 编译器省略了异常、流，甚至嵌套深度超过 N 的模板，但没有一个编译器放弃了多重继承。我真的不明白多重继承如何成为一个特定的空间或速度问题，或者至少比一般的虚拟函数更严重。
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.
对旧答案感到抱歉，但令人难以置信的是，截至 2014 年发布，仍然具有相关性：
Apple OS X、XNU Kernel Compiler 内核级 I/O Kit 驱动程序 (libkern) 不支持多重继承。
< strong>来自 Mac 开发者库：
是的，它仍然存在于真实系统的生产环境中。虽然不多，但确实存在。当您为未完成的硬件编码时，这种情况更常见，因为编译器的端口也可能未完成。
作为编写大量低级框架的人，我完全希望今年我能使用 C11……永远不会。亚格。
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:
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.