標準C++編程：虛函數與內聯
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]
曾經，我們常常在談及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()函數會輸出書名、作者等等。在此之前，它先調用基類的L
ibraryMaterial::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++ Repo
rt，“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 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.