c++ - C++ 中的内联成员函数

Question

ISO C++ 说 C++ 中成员函数的内联定义与用内联声明它是一样的。这意味着该函数将在使用该成员函数的每个编译单元中定义。但是，如果函数调用由于某种原因不能被内联，则函数将“像往常一样”被实例化。 ( http://msdn.microsoft.com/en-us/library/z8y1yy88%28VS.71%29.aspx ) 我对这个定义的问题是它没有说明它将在哪个翻译单元中被实例化。我遇到的问题是，当面对单个静态库中的两个目标文件时，它们都引用了一些无法内联的内联成员函数，链接器可能会“选择”任意目标文件作为定义的源。这种特殊的选择可能会引入不需要的依赖关系。 (除其他外)

例如:在静态库中

A.h:

class A{
  public:
    virtual bool foo() { return true; }
};

U1.cpp:

A a1;

U2.cpp:

A a2;

还有很多依赖

在另一个项目中main.cpp:

#include "A.h"

int main(){
  A a;
  a.foo();
  return 0;
}

第二个项目是指第一个项目。我如何知道编译器将使用哪个定义，以及哪些目标文件及其依赖项将被链接到？标准对此有什么规定吗？ (试过了，没找到)

谢谢

编辑:因为我看到有些人误解了问题是什么，所以我想强调一下:如果编译器决定为该函数创建一个符号(在这种情况下，它会，因为“虚拟性”，在不同的目标文件中会有几个(外部可见的)实例化，链接器会选择哪个定义(从哪个目标文件？)

Answer 1

只有我的两分钱。这不是特别关于虚函数，而是关于内联函数和成员函数。也许有用。

C++

就标准 C++ 而言，内联函数必须在每个使用它的翻译单元中定义。并且非静态内联函数将在每个翻译单元中具有相同的静态变量和相同的地址。编译器/链接器必须将多个定义合并到一个函数中才能实现这一点。因此，始终将内联函数的定义放在头文件中 - 如果您仅在实现文件(“.cpp”)(对于非成员函数)中定义它，则不要将其声明放入头文件中，因为如果您如果有人使用它，您会收到有关未定义函数或类似内容的链接器错误。

这与必须在整个程序中定义一次的非内联函数不同(one-definition-rule)。对于内联函数，如上所述的多个定义是相当正常的情况。这与调用是否最终内联无关。关于内联函数的规则仍然很重要。 Microsoft 编译器是否遵守这些规则 - 我不能告诉你。如果它在这方面遵守标准，那么它会。但是，我可以想象一些使用虚拟、dll 和不同 TU 的组合可能会出现问题。我从未测试过，但我相信没有问题。

对于成员函数，如果你在类中定义你的函数，它是隐式内联的。由于它出现在标题中，因此必须在使用它的每个翻译单元中定义它的规则会自动得到满足。但是，如果您在类外和头文件中定义函数(例如，因为两者之间存在循环依赖关系)，那么如果您多次包含相应的文件，则该定义必须是内联的，以避免链接器引发的多定义错误。 f.h 文件示例:

struct f {
    // inline required here or before the definition below
    inline void g();
};

void f::g() { ... }

这与将定义直接放入类定义中具有相同的效果。

C99

请注意，C99 的内联函数规则比 C++ 更复杂。这里，一个内联函数可以定义为一个内联定义，在整个程序中可以存在多个。但是如果使用这样的(内联)定义(例如，如果它被调用)，那么在另一个翻译中包含的整个程序中必须也有恰好一个外部定义单元。基本原理(引自解释 C99 几个特性背后基本原理的 PDF):

Inlining in C99 does extend the C++ specification in two ways. First, if a function is declared inline in one translation unit, it need not be declared inline in every other translation unit. This allows, for example, a library function that is to be inlined within the library but available only through an external definition elsewhere. The alternative of using a wrapper function for the external function requires an additional name; and it may also adversely impact performance if a translator does not actually do inline substitution.

Second, the requirement that all definitions of an inline function be "exactly the same" is replaced by the requirement that the behavior of the program should not depend on whether a call is implemented with a visible inline definition, or the external definition, of a function. This allows an inline definition to be specialized for its use within a particular translation unit. For example, the external definition of a library function might include some argument validation that is not needed for calls made from other functions in the same library. These extensions do offer some advantages; and programmers who are concerned about compatibility can simply abide by the stricter C++ rules.

我为什么要在此处包含 C99？因为我知道微软编译器支持 C99 的一些东西。所以在那些 MSDN 页面中，一些东西也可能来自 C99——虽然没有特别想出任何东西。在阅读它并将这些技术应用于自己的旨在成为可移植 C++ 的 C++ 代码时，应该小心。可能会告知哪些部分是 C99 特定的，哪些不是。

comeau online compiler 是测试小型 C++ 片段是否符合标准的好地方。 .如果它被拒绝，可以很确定它不是严格符合标准的。