woaidongmao

C++編譯器必須實現語言的每一個特性。這些實現的細節當然是由編譯器來決定的，并且不同的編譯器有不同的方法實現語言的特性。在多數情況下，我們不用關心這些事情。然而有些特性的實現對對象大小和其成員函數執行速度有很大的影響，所以對于這些特性有一個基本的了解，知道編譯器可能在背后做了些什么，就顯得很重要。這種特性中最重要的例子是虛擬函數。

　　當調用一個虛擬函數時，被執行的代碼必須與調用函數的對象的動態類型相一致；指向對象的指針或引用的類型是不重要的。編譯器如何能夠高效地提供這種行為呢？大多數編譯器是使用virtual table和virtual table pointers。virtual table和virtual table pointers通常被分別地稱為vtbl和vptr。

　　一個vtbl通常是一個函數指針數組。（一些編譯器使用鏈表來代替數組，但是基本方法是一樣的）在程序中的每個類只要聲明了虛函數或繼承了虛函數，它就有自己的vtbl，并且類中vtbl的項目是指向虛函數實現體的指針。例如，如下這個類定義：
　　class C1 {
　　public:
　　　C1();

　　　virtual ~C1();
　　　virtual void f1();
　　　virtual int f2(char c) const;
　　　virtual void f3(const string& s);

　　　void f4() const;
　　　...
　　};
　　C1的virtual table數組看起來如下圖所示：     

　　注意非虛函數f4不在表中，而且C1的構造函數也不在。非虛函數（包括構造函數，它也被定義為非虛函數）就象普通的C函數那樣被實現，所以有關它們的使用在性能上沒有特殊的考慮。

　　如果有一個C2類繼承自C1，重新定義了它繼承的一些虛函數，并加入了它自己的一些虛函數，
　　class C2: public C1 {
　　public:
　　　C2();                       // 非虛函數
　　　virtual ~C2();              // 重定義函數
　　　virtual void f1();         // 重定義函數
　　　virtual void f5(char *str); // 新的虛函數
　　　...
　　};

　　它的virtual table項目指向與對象相適合的函數。這些項目包括指向沒有被C2重定義的C1虛函數的指針：

　　這個論述引出了虛函數所需的第一個代價：必須為每個包含虛函數的類的virtual talbe留出空間。類的vtbl的大小與類中聲明的虛函數的數量成正比（包括從基類繼承的虛函數）。每個類應該只有一個virtual table，所以virtual table所需的空間不會太大，但是如果有大量的類或者在每個類中有大量的虛函數，會發現vtbl會占用大量的地址空間。

　　因為在程序里每個類只需要一個vtbl拷貝，所以編譯器肯定會遇到一個棘手的問題：把它放在哪里。大多數程序和程序庫由多個object（目標）文件連接而成，但是每個object文件之間是獨立的。哪個object文件應該包含給定類的vtbl呢？可能會認為放在包含main函數的object文件里，但是程序庫沒有main，而且無論如何包含main的源文件不會涉及很多需要vtbl的類。編譯器如何知道它們被要求建立那一個vtbl呢？

　　必須采取一種不同的方法，編譯器廠商為此分成兩個陣營。對于提供集成開發環境（包含編譯程序和連接程序）的廠商，一種干脆的方法是為每一個可能需要vtbl的object文件生成一個vtbl拷貝。連接程序然后去除重復的拷貝，在最后的可執行文件或程序庫里就為每個vtbl保留一個實例。

  更普通的設計方法是采用啟發式算法來決定哪一個object文件應該包含類的vtbl。通常啟發式算法是這樣的：要在一個object文件中生成一個類的vtbl，要求該object文件包含該類的第一個非內聯、非純虛擬函數（non-inline non-pure virual function）定義（也就是類的實現體）。因此上述C1類的vtbl將被放置到包含C1::~C1定義的object文件里（不是內聯的函數），C2類的vtbl被放置到包含C1::~C2定義的object文件里（不是內聯函數）。

　　實際當中，這種啟發式算法效果很好。如果在類中的所有虛函數都內聲明為內聯函數，啟發式算法就會失敗，大多數基于啟發式算法的編譯器會在每個使用它的object文件中生成一個類的vtbl。在大型系統里，這會導致程序包含同一個類的成百上千個vtbl拷貝！大多數遵循這種啟發式算法的編譯器會給出一些方法來人工控制vtbl的生成，但是一種更好的解決此問題的方法是避免把虛函數聲明為內聯函數。下面將看到，有一些原因導致現在的編譯器一般總是忽略虛函數的的inline指令。

　　Virtual table只實現了虛擬函數的一半機制，如果只有這些是沒有用的。只有用某種方法指出每個對象對應的vtbl時，它們才能使用。這是virtual table pointer的工作，它來建立這種聯系。

  每個聲明了虛函數的對象都帶有它，它是一個看不見的數據成員，指向對應類的virtual table。這個看不見的數據成員也稱為vptr，被編譯器加在對象里，位置只有才編譯器知道。從理論上講，我們可以認為包含有虛函數的對象的布局是這樣的：

　　它表示vptr位于對象的底部，但是不要被它欺騙，不同的編譯器放置它的位置也不同。存在繼承的情況下，一個對象的vptr經常被數據成員所包圍。如果存在多繼承(Multiple inherita-nce)，這幅圖片會變得更復雜?，F在只需簡單地記住虛函數所需的第二個代價是：在每個包含虛函數的類的對象里，必須為額外的指針付出代價。

　　如果對象很小，這是一個很大的代價。比如如果對象平均只有4比特的成員數據，那么額外的vptr會使成員數據大小增加一倍（假設vptr大小為4比特）。在內存受到限制的系統里，這意味著必須減少建立對象的數量。即使在內存沒有限制的系統里，也會發現這會降低軟件的性能，因為較大的對象有可能不適合放在緩存（cache）或虛擬內存頁中(virtual memory page)，這就可能使得系統換頁操作增多。

　　假如我們有一個程序，包含幾個C1和C2對象。對象、vptr和剛才我們講到的vtbl之間的關系，就很復雜.

　　考慮這段這段程序代碼：
　　void makeACall(C1 *pC1)
　　{
　　　pC1->f1();
　　}

　　通過指針pC1調用虛擬函數f1。僅僅看這段代碼，不會知道它調用的是那一個f1函數――C1::f1或C2::f1，因為pC1可以指向C1對象也可以指向C2對象。盡管如此編譯器仍然得為在makeACall的f1函數的調用生成代碼，它必須確保無論pC1指向什么對象，函數的調用必須正確。編譯器生成的代碼會做如下這些事情：
　　1． 通過對象的vptr找到類的vtbl。這是一個簡單的操作，因為編譯器知道在對象內哪里能找到vptr（畢竟是由編譯器放置的它們）。因此這個代價只是一個偏移調整（以得到vptr）和一個指針的間接尋址（以得到vtbl）。
　　2． 找到對應vtbl內的指向被調用函數的指針（在上例中是f1）。這也是很簡單的，因為編譯器為每個虛函數在vtbl內分配了一個唯一的索引。這步的代價只是在vtbl數組內的一個偏移。
    3． 調用第二步找到的的指針所指向的函數。
　　如果假設每個對象有一個隱藏的數據叫做vptr，而且f1在vtbl中的索引為i，此語句
　　pC1->f1();
　　生成的代碼就是這樣的
 (*pC1->vptr[i])(pC1);
 // 調用被vtbl中第i個單元指向的函數，而pC1->vptr 指向的是vtbl；pC1被做為this指針傳遞給函數。

　　這幾乎與調用非虛函數效率一樣。在大多數計算機上它多執行了很少的一些指令。調用虛函數所需的代價基本上與通過函數指針調用函數一樣。虛函數本身通常不是性能的瓶頸。

　　在實際運行中，虛函數所需的代價與內聯函數有關。實際上虛函數不能是內聯的。這是因為“內聯”是指“在編譯期間用被調用的函數體本身來代替函數調用的指令，”但是虛函數的“虛”是指“直到運行時才能知道要調用的是哪一個函數?！比绻幾g器在某個函數的調用點不知道具體是哪個函數被調用，就能知道為什么它不會內聯該函數的調用。這是虛函數所需的第三個代價：實際上放棄了使用內聯函數。（當通過對象調用的虛函數時，它可以被內聯，但是大多數虛函數是通過對象的指針或引用被調用的，這種調用不能被內聯。因為這種調用是標準的調用方式，所以虛函數實際上不能被內聯。）

　　現在為止討論的東西適用于單繼承和多繼承，但是多繼承的引入，事情就會變得更加復雜。詳細論述其細節，在多繼承里，在對象里為尋找vptr而進行的偏移量計算會變得更復雜。在單個對象里有多個vptr（一個基類對應一個）；除了已經討論過的單獨的vtbl以外，還得為基類生成特殊的vtbl。因此增加了每個類和每個對象中的虛函數額外占用的空間，而且運行時調用所需的代價也增加了一些。

　　多繼承經常導致對虛基類的需求。沒有虛基類，如果一個派生類有一個以上從基類的繼承路徑，基類的數據成員被復制到每一個繼承類對象里，繼承類與基類間的每條路徑都有一個拷貝。程序員一般不會希望發生這種復制，而把基類定義為虛基類則可以消除這種復制。然而虛基類本身會引起它們自己的代價，因為虛基類的實現經常使用指向虛基類的指針做為避免復制的手段，一個或者更多的指針被存儲在對象里。

　　例如考慮下面這幅圖，我經常稱它為“恐怖的多繼承菱形”（the dreaded multiple inheritance diamond）

class A{…};                              A
class B: Virtual public A {…};       B       C
class C: Virtual public A {…};           D
class D: public B,public C {…};

　　這里A是一個虛基類，因為B和C虛擬繼承了它。使用一些編譯器（特別是比較老的編譯器），D對象會產生這樣布局：

　　把基類的數據成員放在對象的最底端，這顯得有些奇怪，但是它經常這么做。當然如何實現是編譯器的自由，它們想怎么做都可以，這幅圖只是虛基類如何導致對象需要額外指針的概念性描述，所以不應該在此范圍以外還使用這幅圖。一些編譯器可能加入更少的指針，還有一些編譯器會使用某種方法而根本不加入額外的指針（這種編譯器讓vptr和vtbl負擔雙重責任）。
    如果我們把這幅圖與前面展示如何把virtual table pointer加入到對象里的圖片合并起來，我們就會認識到如果在上述繼承體系里的基類A有任何虛函數，對象D的內存布局就是這樣的：

　　這里對象中被編譯器加入的部分，已經做了陰影處理。這幅圖可能會有誤導，因為陰影部分與非陰影部分之間的面積比例由類中數據量決定。對于小類，額外的代價就大。對于包含更多數據的類，相對來說額外的代價就不大，盡管也是值得注意的。

    還有一點奇怪的是雖然存在四個類，但是上述圖表只有三個vptr。只要編譯器喜歡，當然可以生成四個vptr，但是三個已經足夠了（它發現B和D能夠共享一個vptr），大多數編譯器會利用這個機會來減少編譯器生成的額外負擔。

   現在已經看到虛函數能使對象變得更大，而且不能使用內聯，我們已經測試過多繼承和虛基類也會增加對象的大小。讓我們轉向最后一個話題，運行時類型識別（RTTI）。

　　RTTI能讓我們在運行時找到對象和類的有關信息，所以肯定有某個地方存儲了這些信息，讓我們查詢。這些信息被存儲在類型為type_info的對象里，你能通過使用typeid操作符訪問一個類的type_info對象。

　　在每個類中僅僅需要一個RTTI的拷貝，但是必須有辦法得到任何對象的信息。實際上這敘述得不是很準確。語言規范上這樣描述：我們保證可以獲得一個對象動態類型信息，如果該類型有至少一個虛函數。這使得RTTI數據似乎有些象virtual function talbe(虛函數表)。每個類只需要信息的一個拷貝，我們需要一種方法從任何包含虛函數的對象里獲得合適的信息。這種RTTI和virtual function table之間的相似點并不是巧合：RTTI被設計為在類的vtbl基礎上實現。

　　例如，vtbl數組的索引0處可以包含一個type_info對象的指針，這個對象屬于該vtbl相對應的類。上述C1類的vtbl看上去象這樣：

　　使用這種實現方法，RTTI耗費的空間是在每個類的vtbl中的占用的額外單元再加上存儲type_info對象的空間。就象在多數程序里virtual table所占的內存空間并不值得注意一樣，也不太可能因為type_info對象大小而遇到問題。

　　下面這個表各是對虛函數、多繼承、虛基類以及RTTI所需主要代價的總結

　　
   看到這個表格以后，會很吃驚，有的宣布“還是應該使用C”。很好。但是請記住如果沒有這些特性所提供的功能，你必須手工編碼來實現。在多數情況下，你的人工模擬可能比編譯器生成的代碼效率更低，穩定性更差。例如使用嵌套的switch語句或層疊的if－then－else語句模擬虛函數的調用，其產生的代碼比虛函數的調用還要多，而且代碼運行速度也更慢。再有，你必須自己人工跟蹤對象類型，這意味著對象會攜帶它們自己的類型標簽（type tag）。因此你不會得到更小的對象。

　　理解虛函數、多繼承、虛基類、RTTI所需的代價是重要的，但是如果需要這些功能，不管采取什么樣的方法都得為此付出代價，理解這點也同樣重要。有時確實有一些合理的原因要繞過編譯器生成的服務。例如隱藏的vptr和指向虛基類的指針會使得在數據庫中存儲C++對象或跨進程移動它們變得困難，所以可能希望用某種方法模擬這些特性，能更加容易地完成這些任務。不過從效率的觀點來看，自己編寫代碼不可能做得比編譯器生成的代碼更好。