標(biāo)準(zhǔn)C++編程：虛函數(shù)與內(nèi)聯(lián)
Josée Lajoie and Stanley Lippman
------------------------------------------------------------------------------
----
[This is the last installment of a column that was being published in C++ Repo
rt magazine. Since the magazine ceased publication before this installment cou
ld be published, Josée Lajoie and Stan Lippman were gracious enough to let us
publish it on the CUJ website. — mb]
曾經(jīng)，我們常常在談及C++時(shí)聽到一個(gè)問題：“虛函數(shù)真的應(yīng)該被申明為內(nèi)聯(lián)嗎？”現(xiàn)在，
我們很少再聽到這個(gè)問題了。反過來，我們現(xiàn)在聽到的是“你不應(yīng)該將print()函數(shù)內(nèi)聯(lián)。
將虛函數(shù)申明為內(nèi)聯(lián)是錯(cuò)誤的。”
這么說有兩個(gè)主要理由：(1)虛函數(shù)是在運(yùn)行期判決的，而內(nèi)聯(lián)是編譯期行為，所以不能從
這個(gè)（內(nèi)聯(lián)）申明上得到任何好處；(2)將虛函數(shù)申明為內(nèi)聯(lián)將造成此函數(shù)在可執(zhí)行文件中
有多份拷貝，因此我們?yōu)橐粋€(gè)無論如何都不能內(nèi)聯(lián)的函數(shù)付出了在空間上的處罰（WQ注，
所謂的內(nèi)聯(lián)函數(shù)非內(nèi)聯(lián)問題）。顯然沒腦子。
只是它并不真的正確。反思一下理由(1)：在很多情況下，虛函數(shù)是靜態(tài)判決的－－尤其是
派生類的虛函數(shù)調(diào)用它的基類版本時(shí)。為什么會(huì)那么做？封裝。一個(gè)很好的例子是析構(gòu)函
數(shù)的靜態(tài)調(diào)用鏈：基類的析構(gòu)函數(shù)被派生類的析構(gòu)函數(shù)觸發(fā)。除了最初的一個(gè)外，所有的
析構(gòu)函數(shù)的調(diào)用都是被靜態(tài)判決的。不讓基類的虛析構(gòu)函數(shù)內(nèi)聯(lián)，就不能從中獲益。這會(huì)
造成很大的差別嗎？如果繼承層次很深，而又有大量的對(duì)象需要析構(gòu)，（答案是）“是的
”。
另外一個(gè)例子不涉及析構(gòu)函數(shù)。想像我們正在設(shè)計(jì)一個(gè)圖書館出借管理程序。我們已經(jīng)將
“位置”放入抽象類LibraryMaterial。當(dāng)申明print()函數(shù)為純虛函數(shù)時(shí)，我們也提供其
定義：打印出對(duì)象的位置。
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()函數(shù)會(huì)輸出書名、作者等等。在此之前，它先調(diào)用基類的L
ibraryMaterial::print()函數(shù)以顯示位置信息。例如：
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派生，引入了一個(gè)二選一的借出策略，并且加入了一些附加信息，比如
講解員、格式等等。這些都將在它的print()函數(shù)中顯示出來。在顯示這些以前，它先調(diào)用
Book::print()：
inline void
AudioBook::
print( ostream &os )
{
// ok, this is resolved statically,
// and therefore is inline expanded ...
Book::print();
os << "narrator:" << _narrator << endl;
}
在這個(gè)例子和析構(gòu)函數(shù)的例子中，派生類的虛方法遞增式地?cái)U(kuò)展其基類版本的功能，并以
調(diào)用鏈的方式被調(diào)用，只有最初一次調(diào)用是由虛體系決定的。這個(gè)沒有被命名的繼承樹設(shè)
計(jì)模式，如果從不將虛函數(shù)申明為內(nèi)聯(lián)的話，顯然會(huì)有些低效。
關(guān)于理由(2)的代碼膨脹問題怎么說？好吧，思考一下。如果寫出，
LibraryMaterial *p =
new AudioBook( "Mason & Dixon",
"Thomas Pynchon", "Johnny Depp" );
// ...
p->print();
此處的print()會(huì)內(nèi)聯(lián)嗎？不，當(dāng)然不會(huì)。這必須在運(yùn)行期經(jīng)過虛體系的判決。Okay。它會(huì)
導(dǎo)致此處的print()函數(shù)有它自己的定義體嗎？也不會(huì)。調(diào)用被編譯為類似于這種形式：
// Pseudo C++ Code
// Possible transformation of p->print()
( *p->_vptr[ 2 ] )( p );
那個(gè)2是print()函數(shù)在相應(yīng)的虛函數(shù)表中的位置。因?yàn)檫@個(gè)對(duì)print()的調(diào)用是通過函數(shù)指
針_vptr[2]進(jìn)行的，編譯器不能靜態(tài)決定被調(diào)用函數(shù)的位置，并且函數(shù)不能被內(nèi)聯(lián)。
當(dāng)然，內(nèi)聯(lián)的虛函數(shù)print()的定義必須出現(xiàn)在可執(zhí)行文件中的某處，代碼才能正確執(zhí)行。
也就是說，至少需要一個(gè)定義體，以便將它的地址放入虛函數(shù)表。編譯器如何決定何時(shí)產(chǎn)
生那一個(gè)定義體的呢？一個(gè)實(shí)現(xiàn)策略是在產(chǎn)生那類的虛函數(shù)表時(shí)同時(shí)產(chǎn)生那個(gè)定義體。這
意味著針對(duì)為一個(gè)類所生成的每個(gè)虛函數(shù)表實(shí)例，每個(gè)內(nèi)聯(lián)的虛函數(shù)的一個(gè)實(shí)例也被產(chǎn)生
。
在可執(zhí)行文件中，為一個(gè)類產(chǎn)生的虛函數(shù)表，實(shí)際上有多少個(gè)？啊，很好，問得好。C++標(biāo)
準(zhǔn)規(guī)定了虛函數(shù)在行為上的要求；但它沒有規(guī)定實(shí)現(xiàn)虛函數(shù)上的要求。既然虛函數(shù)表的存
在不是C++標(biāo)準(zhǔn)所要求的，明顯標(biāo)準(zhǔn)也沒有進(jìn)一步要求如何處理虛函數(shù)表以及生成多少次。
最佳的數(shù)目當(dāng)然是“一次”。例如，Stroustrup的原始cfront實(shí)現(xiàn)版本，在大部份情況下
聰明地達(dá)成了這一點(diǎn)。 (Stan和Andy Koenig描述了其算法，發(fā)表于1990年3月，C++ Repo
rt，“Optimizing Virtual Tables in C++ Release 2.0.”)
此外，C++標(biāo)準(zhǔn)現(xiàn)在要求內(nèi)聯(lián)函數(shù)的行為要滿足好象程序中只存在一個(gè)定義體，即使這個(gè)函
數(shù)可能被定義在不同的文件中。新的規(guī)則是說滿足規(guī)定的實(shí)現(xiàn)版本，行為上應(yīng)該好象只生
成了一個(gè)實(shí)例。一旦標(biāo)準(zhǔn)的這一點(diǎn)被廣泛采用，對(duì)內(nèi)聯(lián)函數(shù)潛在的代碼膨脹問題的關(guān)注應(yīng)
該消失了。
C++社群中存在著一個(gè)沖突：教學(xué)上需要規(guī)則表現(xiàn)為簡(jiǎn)單的檢查表vs實(shí)踐中需要明智地依據(jù)
環(huán)境而運(yùn)用規(guī)則。前者是對(duì)語言的復(fù)雜度的回應(yīng)；后者，是對(duì)我們構(gòu)造的解決方案的復(fù)雜
度的回應(yīng)。何時(shí)將虛函數(shù)申明為內(nèi)聯(lián)的問題，是這種沖突的一個(gè)很好的例證。
About the Authors
Stanley Lippman was the software Technical Director for the Firebird segment o
f Disney's Fantasia 2000. He was recently technical lead on the ToonShooter im
age capture and playback system under Linux for DreamWorks Feature Animation a
nd consulted with the Jet Propulsion Laboratory. He is currently IT Training P
rogram 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 t
he University Waterloo. Previously, she was a member of the C/C++ compiler dev
elopment team at the IBM Canada Laboratory and was the chair of the core langu
age working group for the ANSI/ISO C++ Standard Committee. She can be reached
at jlajoie@cgl.uwaterloo.ca.