虛函數
當調用一個虛擬函數時，被執行的代碼必須與調用函數的對象的動態類型相一致；指向對象的指針或引用的類型是不重要的。編譯器如何能夠高效地提供這種行爲呢？大多數編譯器是使用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虛函數的指針(但是不包含C1的虛析構函數)：
1.這個論述引出了虛函數所需的第一個代價：你必須爲每個包含虛函數的類的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文件裏（不是內聯函數）。（類中的非虛函數默認爲內聯的，而虛函數不能是內聯的，因爲要發生動態綁定！）
實際當中，這種啓發式算法效果很好。但是如果你過分喜歡聲明虛函數爲內聯函數（參見Effective C++條款33），如果在類中的所有虛函數都內聲明爲內聯函數，啓發式算法就會失敗，大多數基於啓發式算法的編譯器會在每個使用它的object文件中生成一個類的vtbl。在大型系統裏，這會導致程序包含同一個類的成百上千個vtbl拷貝！大多數遵循這種啓發式算法的編譯器會給你一些方法來人工控制vtbl的生成，但是一種更好的解決此問題的方法是避免把虛函數聲明爲內聯函數。下面我們將看到，有一些原因導致現在的編譯器一般總是忽略虛函數的的inline指令。
（C++ Primer 第五版中指出：內聯說明只是向編譯器發出一個請求，編譯器可以選擇忽略這個請求。）
Virtual table只實現了虛擬函數的一半機制，如果只有這些是沒有用的。只有用某種方法指出每個對象對應的vtbl時，它們才能使用。這是virtual table pointer的工作，它來建立這種聯繫。
每個聲明瞭虛函數的對象都帶有它，它是一個看不見的數據成員，指向對應類的virtual table。這個看不見的數據成員也稱爲vptr，被編譯器加在對象裏，只有編譯器才知道。從理論上講，我們可以認爲包含有虛函數的對象的佈局是這樣的：
這幅圖片表示vptr位於對象的底部，但是不要被它欺騙，不同的編譯器放置它的位置也不同。存在繼承的情況下，一個對象的vptr經常被數據成員所包圍。如果存在多繼承(Multiple inheritance)，這幅圖片會變得更復雜，等會兒我們將討論它。
2.虛函數所需的第二個代價是：在每個包含虛函數的類的對象裏，你必須爲額外的指針付出代價。
如果對象很小，這是一個很大的代價。比如如果你的對象平均只有4比特的成員數據，那麼額外的vptr會使成員數據大小增加一倍（假設vptr大小爲4比特，32爲系統）。在內存受到限制的系統裏，這意味着你必須減少建立對象的數量。即使在內存沒有限制的系統裏，你也會發現這會降低軟件的性能，因爲較大的對象有可能不適合放在緩存（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指向什麼對象，函數的調用必須正確。編譯器生成的代碼會做如下這些事情：
- 通過對象的vptr找到類的vtbl。這是一個簡單的操作，因爲編譯器知道在對象內哪裏能找到vptr（畢竟是由編譯器放置的它們）。因此這個代價只是一個偏移調整（以得到vptr）和一個指針的間接尋址（以得到vtbl）。
- 找到對應vtbl內的指向被調用函數的指針（在上例中是f1）。這也是很簡單的，因爲編譯器爲每個虛函數在vtbl內分配了一個唯一的索引。這步的代價只是在vtbl數組內的一個偏移。
- 調用第二步找到的的指針所指向的函數。
- pC1->f1();
- (*pC1->vptr[i])(pC1); //調用被vtbl中第i個單元指
- // 向的函數，而pC1->vptr
- //指向的是vtbl；pC1被做爲
- // this指針傳遞給函數。
這幾乎與調用非虛函數效率一樣。在大多數計算機上它多執行了很少的一些指令。調用虛函數所需的代價基本上與通過函數指針調用函數一樣。虛函數本身通常不是性能的瓶頸。
在實際運行中，虛函數所需的代價與內聯函數有關。實際上虛函數不能是內聯的。這是因爲“內聯”是指“在編譯期間用被調用的函數體本身來代替函數調用的指令，”但是虛函數的“虛”是指“直到運行時才能知道要調用的是哪一個函數。”如果編譯器在某個函數的調用點不知道具體是哪個函數被調用，你就能知道爲什麼它不會內聯該函數的調用。
3.這是虛函數所需的第三個代價：你實際上放棄了使用內聯函數。
（當通過對象調用虛函數時，它可以被內聯，但是大多數虛函數是通過對象的指針或引用被調用的，這種調用不能被內聯。因爲這種調用是標準的調用方式，所以虛函數實際上不能被內聯。）
到現在爲止我們討論的東西適用於單繼承和多繼承，但是多繼承的引入，事情就會變得更加複雜（參見Effective C++條款43）。這裏詳細論述其細節，但是在多繼承裏，在對象裏爲尋找vptr而進行的偏移量計算會變得更復雜。在單個對象裏有多個vptr（每一個基類對應一個）；除了我們已經討論過的單獨的自己的vtbl以外，還得爲基類生成特殊的vtbl。因此增加了每個類和每個對象中的虛函數額外佔用的空間，而且運行時調用所需的代價也增加了一些。
虛基類
多繼承經常導致對虛基類的需求。沒有虛基類，如果一個派生類有一個以上從基類的繼承路徑，基類的數據成員被複製到每一個繼承類對象裏，繼承類與基類間的每條路徑都有一個拷貝。程序員一般不會希望發生這種複製，而把基類定義爲虛基類則可以消除這種複製。然而虛基類本身會引起它們自己的代價，因爲虛基類的實現經常使用指向虛基類的指針做爲避免複製的手段，一個或者更多的指針被存儲在對象裏。
例如考慮下面這幅圖，我經常稱它爲“恐怖的多繼承菱形”（the dreaded multiple inheritance diamond）
這裏A是一個虛基類，因爲B和C虛擬繼承了它。使用一些編譯器（特別是比較老的編譯器），D對象會產生這樣佈局：
把基類的數據成員放在對象的最底端，這顯得有些奇怪，但是它經常這麼做。當然如何實現是編譯器的自由，它們想怎麼做都可以，這幅圖只是虛基類如何導致對象需要額外指針的概念性描述，所以你不應該在此範圍以外還使用這幅圖。一些編譯器可能加入更少的指針，還有一些編譯器會使用某種方法而根本不加入額外的指針（這種編譯器讓vptr和vtbl負擔雙重責任）。
如果我們把這幅圖與前面展示如何把virtual table pointer加入到對象裏的圖片合併起來，我們就會認識到如果在上述繼承體系裏的基類A有任何虛函數，對象D的內存佈局就是這樣的：
這裏對象中被編譯器加入的部分，我已經做了陰影處理。這幅圖可能會有誤導，因爲陰影部分與非陰影部分之間的面積比例由類中數據量決定。對於小類，額外的代價就大。對於包含更多數據的類，相對來說額外的代價就不大，儘管也是值得注意的。
還有一點奇怪的是雖然存在四個類，但是上述圖表只有三個vptr(每個基類生成一個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所需主要代價的總結：
|
Feature |
Increases |
Increases |
Reduces |
|
Virtual Functions |
Yes |
Yes |
Yes |
|
Multiple Inheritance |
Yes |
Yes |
No |
|
Virtual Base Classes |
Often |
Sometimes |
No |
|
RTTI |
No |
Yes |
No |
一些人看到這個表格以後，會很喫驚，他們宣佈“我還是應該使用C”。很好。但是請記住如果沒有這些特性所提供的功能，你必須手工編碼來實現。在多數情況下，你的人工模擬可能比編譯器生成的代碼效率更低，穩定性更差。例如使用嵌套的switch語句或層疊的if－then－else語句模擬虛函數的調用，其產生的代碼比虛函數的調用還要多，而且代碼運行速度也更慢。再有，你必須自己人工跟蹤對象類型，這意味着對象會攜帶它們自己的類型標籤（type tag）。因此你不會得到更小的對象。
理解虛函數、多繼承、虛基類、RTTI所需的代價是重要的，但是如果你需要這些功能，不管採取什麼樣的方法你都得爲此付出代價，理解這點也同樣重要。有時你確實有一些合理的原因要繞過編譯器生成的服務。例如隱藏的vptr和指向虛基類的指針會使得在數據庫中存儲C++對象或跨進程移動它們變得困難，所以你可能希望用某種方法模擬這些特性，能更加容易地完成這些任務。不過從效率的觀點來看，你自己編寫代碼不可能做得比編譯器生成的代碼更好。