为虚拟析构函数指定的冲突类型属性 [英] Conflicting type attributes specified for virtual destructor

问题描述

以下摘录以前是在Borland C ++，MSVC和OpenWatcom下编译的：

  class aaa {
 virtual _fastcall 〜AAA（）; 
}; 
 
 class bbb：public aaa {
}; 
  

它不能在gcc / g ++下编译（MinGW 4.8.0）。错误：

 
 probz.cpp：7：7：错误：为'virtual bbb ::〜bbb（）'指定的冲突类型属性
 class bbb：public aaa {
 ^ 
 probz.cpp：3：20：error：overriding'virtual aaa ::〜aaa（）'
 virtual _fastcall〜aaa（）= 0; ///不能是抽象的
 ^ 
 

显然，没有bbb ::〜bbb（）！

编辑

实际的类层级较大，有很多类 bbb 从 aaa 继承，并且在它们之间存在中间成员，即bbb extends abb，它扩展了aab，从而扩展了aaa。 aaa 确实有一个抽象的虚拟析构函数，它可以在中间类中实现，但不在叶中。是的，我可以删除 __ fastcall 属性并编译。这是一个gcc限制，我无法调整调用约定吗？

__ fastcall 是一个调用约定。

这是一个非标准功能：名称开头的双下划线表示它是特定实现。调用约定与系统和CPU体系结构紧密相关。这似乎与x86 32位模式有关。

一些建议：

• （例如，当与预编译的库或连接时）。


• 优化现代编译器所执行的优化级别并不经常需要这样的手动优化。关键字 register
同样适用

• 如果你的代码在某些平台上真的需要它，你应该预见一个 #define ，并确保在条件编译时，它在平台/编译器中与其无关（对于DLL而言，这种方法通常是特定库的#define ）。


• 调用约定在所有派生类中应该是相同的，所以最好在基类中声明。对于虚拟功能，这是一个隐含的强制性要求！假设您的基类通过堆栈传递参数，并通过寄存器（fastcall）传递派生类。现在，如果通过基类指针进行多态调用，编译器应该生成哪些代码？如果两个派生类会使用不同的调用约定会发生什么？


• 您不能假定调用约定是自动继承的：标准不保证，这里


• 如果您必须指定调用对话，如果可能的话（例如 externC）更喜欢外部链接说明符，因为这是标准支持的唯一调用约定相关语义。

其他信息：

• __ cdecl ， __stdcall 和其他常用的调用约定


• 呼叫召集通知

The following extract was previously compiling under Borland C++, MSVC and OpenWatcom:

class aaa {
    virtual _fastcall ~aaa();
};

class bbb:public aaa {
};

It doesn't compile under gcc/g++ (MinGW 4.8.0). Error:

probz.cpp:7:7: error: conflicting type attributes specified for 'virtual bbb::~bbb()'
 class bbb:public aaa {
       ^
probz.cpp:3:20: error:   overriding 'virtual aaa::~aaa()'
   virtual _fastcall ~aaa()=0;///can't be abstract
                     ^

Obviously, there is no bbb::~bbb()!

EDIT

The actual class hierarchy is bigger, there are many classes bbb inheriting from aaa, and there are intermediate members in between, i.e. bbb extends abb, which extends aab, which extends aaa. aaa indeed has an abstract virtual destructor, which gets implementation in the intermediate classes, but not in the leaves. Yes, I can remove the __fastcall attribute and it compiles. Is it a gcc limitation that I cannot adjust the calling convention?

解决方案

The __fastcall is a calling convention.

It's a non standard feature : the double underscore at the begin of the name means that it's implementation specific. Calling conventions are tightly related to the systems and CPU architectures. This one seems to be relevant for x86 32 bit mode.

Some recommendations:

• You shouldn't bother with calling conventions unless absolutely required (e.g.when interfacing with precompiled libraries or extern dlls).
• The level of optimizing that modern compilers perform does no longuer require such manual tuning. The same applies with keyword register
• If your code really needs it on some platforms, you should foresee a #define in one of your header and make sure with conditional compilation that it's defined to nothing on platform/compilers where it's not relevant (for DLLs this approach is usual, with a library specific #define).
• Calling conventions should be the same in all the derived classes, so it's better declared in the base class. For virtual functions this is an implicitely mandatory requirement ! Imagine that your base class passes parameters via the stack, and the derived class via the registers (fastcall). Now what code should your compiler generate if you make a polymorphic call via a base class pointer ? And what would happen if two derived classes would use different calling conventions ?
• You can't assume that a calling convention is automatically inherited : the standard makes no guarantee, here
• If you have to specify a calling convetion, prefer an external linkage specifier if possible (e.g. extern "C" ) because this is the only calling convention relevant semantic that is supported by the standard.

Additional information:

• __cdecl, __stdcall, and other usual calling conventions
• Calling convetions demistified

这篇关于为虚拟析构函数指定的冲突类型属性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！