虚函数什么情况下会内联

最近有个朋友研究了一下虚函数内联的问题，我也对这个问题产生了兴趣，发现网上也有好多讨论这个问题的，众说纷纭，于是花了点时间研究了一下。
自己在vc下做了一些实验，通过观察各种情况下汇编代码，以及了一些资料的记载得出以下结论:

虚函数是可以内联的

据我所知有3种情况会内联展开：

1.“虚函数静态调用”，像这样
pclass->class::vf()
或者在类体内调用class::vf() //相当于this->class::vf()
这种调用方式其实类似第二种调用方式。
如果你可以肯定你要调用的函数，并且这个函数不需要运行时刻确定的数据。就可以这样写来提高效率。不错吧:)

2.用一个类对象通过成员选择符.调用虚函数，如
obj.vf()
这时虚函数vf()就可以被vc优化内联展开。
这样调用等于告诉编译器你要调用的具体函数，在函数有inline修饰或是体内定义的情况下就会被内联展开。

3.虚析构函数的静态调用链一定会被内联展开（Lippman文章提到的，见后附文章）

不会内联的情况:
用类指针调用虚函数如
pclass->vf()
这时vf()无论如何不会被内联展开。（即便使用__forceinline关键字强制内联也不行，最终他还是一个非inline函数。）
通过类指针调用虚函数，由于虚函数的多态性，那就意味着你在告诉编译器，这是一个需要在运行时“动态”调用的函数，不要把它内联。

----------------------------------------------------------------------------------

相关资料：

《Effective C++》的第33款:
即使是最简单的虚函数调用，编译器的内联处理程序对它也爱莫能助。（这一点也不奇怪。virtual的意思是"等到运行时再决定调用哪个函数"，inline的意思是"在编译期间将调用之处用被调函数来代替"，如果编译器甚至还不知道哪个函数将被调用，当然就不能责怪它拒绝生成内联调用了）。

这个结论显然是错的，Lippman的文章里说的很清楚了，至少虚析构函数静态调用链一定会被内联。
但是我清楚记得这本书的另一个条款很清楚的说明了关于虚函数内联的实际情况，简直和这里的说法自相矛盾。（时间久了具体记不清是哪一款了）所以我认为《Effective C++》的作者本人应该十分清楚关于虚函数内联的实际情况，如果你仔细看完他的书应该也不会被误导，这里之所以这样写也许只是他的一时笔误，或者作者觉得没必要在这里提到那些“特殊的”情况吧。

----------------------------------------------------------------------------------

然后，在《Inside the C++ Object Model》
第五章Presence of a Virtual Specification节
末尾有这样一段话

However, couldn't a compiler, through analysis, determine that only a single instance of the function exists within the class hierarchy. In so doing, could it not transform the call into a static invocation, thereby allowing for the inline expansion of the call? But what happens if the hierarchy is subsequently added to and the new class introduces a new instance of the function? This new class invalidates the optimization. The function must now be recompiled (or perhaps a second, polymorphic instance generated, with the compiler determining through flow analysis which instance needs to be invoked). The function, however, may exist as a binary within a library. Unearthing this dependency is likely to require some form of persistent program database or library manager.
大概意思说如果编译器把虚函数调用转化成静态调用并内联展开，一旦类层次体系改变，加入新的类就会破坏这种优化。而函数有可能以二进制形式存在于库中，编译器很难挖掘出这样的相依性。

----------------------------------------------------------------------------------

最后，这篇最重要的文章
Standard C++ Programming: Virtual Functions and Inlining

Josée Lajoie and Stanley Lippman
] 01, 2000

----------------------------------------------------------------------------------

[This is the last installment of a column that was being published in C++ Report magazine. Since the magazine ceased publication before this installment could be published, Josée Lajoie and Stan Lippman were gracious enough to let us publish it on the CUJ website. — mb]

 

曾经，我们常常在谈及C++时听到一个问题：“虚函数真的应该被申明为内联吗？”现在，我们很少再听到这个问题了。反过来，我们现在听到的是“你不应该将print()函数内联。将虚函数申明为内联是错误的。”

这么说有两个主要理由：(1)虚函数是在运行期判决的，而内联是编译期行为，所以不能从这个（内联）申明上得到任何好处；(2)将虚函数申明为内联将造成此函数在可执行文件中有多份拷贝，因此我们为一个无论如何都不能内联的函数付出了在空间上的处罚（WQ注，所谓的内联函数非内联问题）。显然没脑子。

只是它并不真的正确。反思一下理由(1)：在很多情况下，虚函数是静态判决的－－尤其是派生类的虚函数调用它的基类版本时。为什么会那么做？封装。一个很好的例子是析构函数的静态调用链：基类的析构函数被派生类的析构函数触发。除了最初的一个外，所有的析构函数的调用都是被静态判决的。不让基类的虚析构函数内联，就不能从中获益。这会造成很大的差别吗？如果继承层次很深，而又有大量的对象需要析构，（答案是）“是的”。

另外一个例子不涉及析构函数。想像我们正在设计一个图书馆出借管理程序。我们已经将“位置”放入抽象类LibraryMaterial。当申明print()函数为纯虚函数时，我们也提供其定义：打印出对象的位置。

class LibraryMaterial {

private:

    MaterialLocation _loc; // shared data

    // ...

 

public:

    // declares pure virtual function

    inline virtual void print( ostream& = cout ) = 0;

};

 

// we actually want to encapsulate the handling of the

// location of the material within a base class

// LibraryMaterial print() method - we just don’t want it

// invoked through the virtual interface. That is, it is

// only to be invoked within a derived class print() method

 

inline void

LibraryMaterial::

print( ostream &os ) { os << _loc; }

 

 

接着引入Book类；它的print()函数会输出书名、作者等等。在此之前，它先调用基类的LibraryMaterial::print()函数以显示位置信息。例如：

inline void

Book::

print( ostream &os )

{

      // ok, this is resolved statically,

      // and therefore is inline expanded ...

      LibraryMaterial::print();

       

      os << "title:" << _title

         << "author" << _author << endl;

}

AudioBook类从Book派生，引入了一个二选一的借出策略，并且加入了一些附加信息，比如讲解员、格式等等。这些都将在它的print()函数中显示出来。在显示这些以前，它先调用Book::print()：

 

inline void

AudioBook::

print( ostream &os )

{

      // ok, this is resolved statically,

      // and therefore is inline expanded ...

      Book::print();

      os << "narrator:" << _narrator << endl;

}

在这个例子和析构函数的例子中，派生类的虚方法递增式地扩展其基类版本的功能，并以调用链的方式被调用，只有最初一次调用是由虚体系决定的。这个没有被命名的继承树设计模式，如果从不将虚函数申明为内联的话，显然会有些低效。

关于理由(2)的代码膨胀问题怎么说？好吧，思考一下。如果写出，

LibraryMaterial *p =

    new AudioBook( "Mason & Dixon",

                   "Thomas Pynchon", "Johnny Depp" );

// ...

p->print();

此处的print()会内联吗？不，当然不会。这必须在运行期经过虚体系的判决。Okay。它会导致此处的print()函数有它自己的定义体吗？也不会。调用被编译为类似于这种形式：

// Pseudo C++ Code

// Possible transformation of p->print()

( *p->_vptr[ 2 ] )( p );

那个2是print()函数在相应的虚函数表中的位置。因为这个对print()的调用是通过函数指针_vptr[2]进行的，编译器不能静态决定被调用函数的位置，并且函数不能被内联。

当然，内联的虚函数print()的定义必须出现在可执行文件中的某处，代码才能正确执行。也就是说，至少需要一个定义体，以便将它的地址放入虚函数表。编译器如何决定何时产生那一个定义体的呢？一个实现策略是在产生那类的虚函数表时同时产生那个定义体。这意味着针对为一个类所生成的每个虚函数表实例，每个内联的虚函数的一个实例也被产生。

在可执行文件中，为一个类产生的虚函数表，实际上有多少个？啊，很好，问得好。C++标准规定了虚函数在行为上的要求；但它没有规定实现虚函数上的要求。既然虚函数表的存在不是C++标准所要求的，明显标准也没有进一步要求如何处理虚函数表以及生成多少次。最佳的数目当然是“一次”。例如，Stroustrup的原始cfront实现版本，在大部份情况下聪明地达成了这一点。 (Stan和Andy Koenig描述了其算法，发表于1990年3月，C++ Report，“Optimizing Virtual Tables in C++ Release 2.0.”)

此外，C++标准现在要求内联函数的行为要满足好象程序中只存在一个定义体，即使这个函数可能被定义在不同的文件中。新的规则是说满足规定的实现版本，行为上应该好象只生成了一个实例。一旦标准的这一点被广泛采用，对内联函数潜在的代码膨胀问题的关注应该消失了。

C++社群中存在着一个冲突：教学上需要规则表现为简单的检查表vs实践中需要明智地依据环境而运用规则。前者是对语言的复杂度的回应；后者，是对我们构造的解决方案的复杂度的回应。何时将虚函数申明为内联的问题，是这种冲突的一个很好的例证。

 

About the Authors
Stanley Lippman was the software Technical Director for the Firebird segment of Disney's Fantasia 2000. He was recently technical lead on the ToonShooter image capture and playback system under Linux for DreamWorks Feature Animation and consulted with the Jet Propulsion Laboratory. He is currently IT Training Program Chair for You-niversity.com, an e-learning training company. He can be reached at stanleyl@you-niversity, www.you-niversity.com, and www.objectwrite.com.

Josée Lajoie is currently doing her Master's degree in Computer Graphics at the University Waterloo. Previously, she was a member of the C/C++ compiler development team at the IBM Canada Laboratory and was the chair of the core language working group for the ANSI/ISO C++ Standard Committee. She can be reached at [email protected].