在MinGW中导入内联函数 [英] Importing inline functions in MinGW

问题描述

这是一个缩减的测试用例，由链接到库的编译单元可以看出（对于库中看到的版本，只需将 dllimport 替换为 dllexport ）。

  class __declspec（dllimport）MyClass {
 public：
 int myFunc2（）; 
 int myFunc1（）; 
}; 
 
 inline int MyClass :: myFunc2（void）{
 return myFunc1（）; 
} 
 
 inline int MyClass :: myFunc1（void）{
 return 0; 
} 
  

编译此操作会发出警告：

警告：'int MyClass :: myFunc1（）'重新声明没有dllimport
属性被dll链接引用[默认启用]

请注意，定义函数的顺序很重要，因为将 myFunc1 的定义放在 myFunc2 的定义导致没有警告。

还要注意，此代码在Visual C ++下编译没有警告。这些警告至少针对MinGW，特别是GCC。编辑：在我看来，我可能需要验证项目设置的标志之一是否禁止警告。

我的问题是： / p>

• 为什么是这样的行为？


• 声明 myFunc1 作为 inline 在类声明内修复问题。这是为什么 ？这也违反了推荐的方式做事情


• 是否有另一个（更好的）方法来解决这个问题？

解决方案

问题出在于dllimport工作方式的一些魔法，通常意味着您只需要在第一个声明中。

，当你将一个函数声明为dllimport，然后用除了dllimport之外的相同声明重新声明函数时，第二个声明隐含地得到dllimport。如果重新声明不一样，它不会得到隐式的dllimport。

所以这里发生的是你首先声明函数为dllimport / non-inline，然后将其声明为非dllimport / inline。在第一个声明中添加内联将修复问题，因为第二个声明变为隐含的dllimport。或者，在第二个声明中添加一个 __ declspec（dllimport）可以解决问题。

请注意，重新排序定义摆脱警告，因为警告是在重新声明之前使用它。通过重新排序，您不再在重新声明之前使用它，因此您不会收到警告，尽管它将使用非dllimport版本（即，它将永远不会使用dll中的函数版本）。 p>

注意，使用内联dllimport是危险的。任何针对dll构建的程序都可能在某些地方使用内联函数，而在其他方面可能使用非内联函数（来自dll）。即使这两个功能现在相同，dll的未来版本可能会改变并具有不同的实现。如果运行新版本的dll，旧计划可能会开始行为不端。

I'm using a shared library that defines inline functions in its header.

Here is a reduced test case, as seen by the compilation unit linking to the library (for the version seen by the library, just replace dllimport by dllexport).

class __declspec(dllimport) MyClass {
public:
    int myFunc2();
    int myFunc1();
};

inline int MyClass::myFunc2(void) {
    return myFunc1();
}

inline int MyClass::myFunc1(void) {
    return 0;
}

Compiling this gives the warning:

warning: 'int MyClass::myFunc1()' redeclared without dllimport attribute after being referenced with dll linkage [enabled by default]

Please note that the order in which the functions are defined is important, as putting the definition of myFunc1 before the definition of myFunc2 results in no warnings.

Note also that this code compiles without warnings under Visual C++. These warnings are specific at least to MinGW, maybe to GCC in general. Edit: it came to my mind that I may have to verify if the warning is not inhibited by one of the flags set by the project.

My questions are then:

• Why this behavior ?
• Declaring myFunc1 as inline inside the class declaration fixes the problem. Why is that ? It's also against the recommended way of doing things.
• Is there another (better ?) way to fix this problem ?

解决方案

The problem comes about because of some magic in the way that dllimport works which normally means you only need it on the first declaration.

Basically, when you declare a function as dllimport and then later redeclare the function with an identical declaration except for the dllimport, the second declaration implicitly gets the dllimport. If the redeclaration is NOT identical, it doesn't get the implicit dllimport.

So what happens here is you first declare the function as dllimport/non-inline, and then declare it as non-dllimport/inline. Adding an inline to the first declaration fixes the problem, as the second then becomes implicitly dllimport. Alternately, adding a __declspec(dllimport) to the second declaration should fix the problem.

Note that reordering the definitions gets rid of the warning, since the warning is about using it before redeclaring it. With a reorder, you're no longer using it before the redeclaration, so you get no warning, though it will be using the non-dllimport version (ie, it will never use the version of the function from the dll).

Note also, using inline dllimport is dangerous. Any program built against the dll might use the inline function in some places and the non-inline function (from the dll) in others. Even if the two functions are identical NOW, a future version of the dll might change and have a different implementation. At which point the old program might start misbehaving if run with the new version of the dll.

这篇关于在MinGW中导入内联函数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！