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

　　當(dāng)調(diào)用一個虛擬函數(shù)時，被執(zhí)行的代碼必須與調(diào)用函數(shù)的對象的動態(tài)類型相一致；指向?qū)ο蟮闹羔樆蛞玫念愋褪遣恢匾摹＞幾g器如何能夠高效地提供這種行為呢？大多數(shù)編譯器是使用virtual table和virtual table pointers。virtual table和virtual table pointers通常被分別地稱為vtbl和vptr。

　　一個vtbl通常是一個函數(shù)指針數(shù)組。（一些編譯器使用鏈表來代替數(shù)組，但是基本方法是一樣的）在程序中的每個類只要聲明了虛函數(shù)或繼承了虛函數(shù)，它就有自己的vtbl，并且類中vtbl的項目是指向虛函數(shù)實現(xiàn)體的指針。例如，如下這個類定義：
　　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數(shù)組看起來如下圖所示：     

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　在實際運行中，虛函數(shù)所需的代價與內(nèi)聯(lián)函數(shù)有關(guān)。實際上虛函數(shù)不能是內(nèi)聯(lián)的。這是因為“內(nèi)聯(lián)”是指“在編譯期間用被調(diào)用的函數(shù)體本身來代替函數(shù)調(diào)用的指令，”但是虛函數(shù)的“虛”是指“直到運行時才能知道要調(diào)用的是哪一個函數(shù)。”如果編譯器在某個函數(shù)的調(diào)用點不知道具體是哪個函數(shù)被調(diào)用，就能知道為什么它不會內(nèi)聯(lián)該函數(shù)的調(diào)用。這是虛函數(shù)所需的第三個代價：實際上放棄了使用內(nèi)聯(lián)函數(shù)。（當(dāng)通過對象調(diào)用的虛函數(shù)時，它可以被內(nèi)聯(lián)，但是大多數(shù)虛函數(shù)是通過對象的指針或引用被調(diào)用的，這種調(diào)用不能被內(nèi)聯(lián)。因為這種調(diào)用是標(biāo)準(zhǔn)的調(diào)用方式，所以虛函數(shù)實際上不能被內(nèi)聯(lián)。）

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

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

　　例如考慮下面這幅圖，我經(jīng)常稱它為“恐怖的多繼承菱形”（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對象會產(chǎn)生這樣布局：

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

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

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

   現(xiàn)在已經(jīng)看到虛函數(shù)能使對象變得更大，而且不能使用內(nèi)聯(lián)，我們已經(jīng)測試過多繼承和虛基類也會增加對象的大小。讓我們轉(zhuǎn)向最后一個話題，運行時類型識別（RTTI）。

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

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

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

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

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

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

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