C++类（vtable）的单独编译器？
我想知道使用一个不允许多重继承的编译器编译类 A 并编译支持多重继承的类 B（以及从类 A 派生的类 B）会产生什么后果。
我不太明白链接过程......是否可以一起使用两者？在这种情况下使用单独的编译器和 vtable 存在哪些缺点？使用B类的代码会不会无法正常运行？
谢谢。
I was wondering what the consequences are for compiling a class A with one compiler that doesn't allow multiple inheritance, and compiling a class B that does support it (and class B derived from class A).
I don't really understand the linking process...would it be possible to use both together? What disadvantages exist for using separate compilers in this situation, with vtables? Would it be impossible for code using class B to function properly?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
作为一般规则，永远不要使用不同的编译器来编译 C++ 程序的某些部分。
不同的编译器可能会并且经常在符号修饰阶段使用不同的修饰模式，因此单独编译的内容之间的链接不太可能起作用。
请参阅有关 mangling 的文档 name_mangling
As a general rule, don't ever compile parts of your C++ program with different compilers.
Different compilers may use, and often do, different mangling schemas for the symbol mangling stage, so it's very unlikely that the linking between separately compiled stuff will work.
See doc about mangling name_mangling
不保证编译器之间的对象布局（vtable 指针位置、vtable 格式、子对象放置等）相同。
Object layout (vtable pointer location, vtable format, sub-object placement, etc.) is not guaranteed to be the same between the compilers.
不仅仅是班级之间无法相互交谈。由于名称修改，在标头中声明但仅由其中一个编译器编译的裸函数对于另一个编译器将是不可见的。
此外，由不编译 main() 的编译器编译的任何静态类/类成员将无法正确初始化，因为该编译器的运行时将不会被执行。即使像 64 位长算术这样的东西（在 32 位平台上）也可能由于运行时库冲突而无法正确链接。
It's not just classes that won't be able to talk to one another. Bare functions declared in a header but compiled only by one of the compilers will be invisible to the other compiler because of name mangling.
Also, any static classes/members of classes compiled by the compiler that does NOT compile main() will not initialize correctly because that compiler's runtime will not be executed. Even things like 64bit long long arithmetic (on 32bit platforms) might not be linked correctly because of the conflicting runtime libraries.
作为上述 Arkaitz 帖子的附录，您可能会发现其他问题，这些问题可能会阻止使用不同编译器构建的编译单元中的代码协同工作：
基本上，C++/C 标准对事物不太具体的任何地方都留下了编译器之间差异的范围，因此也存在混合它们的问题的范围
As an addendum to Arkaitz's post above, you may find other issues that could stop code working together from compilation units built with different compilers:
Basically anywhere that the C++/C standards isn't very specific about things leaves scope for differences between compilers, and hence scope for problems mixing them