RTTI、虛函數(shù)和虛基類的開銷分析及使用指導
白楊
“在正確的場合使用恰當?shù)奶匦?#8221; 對稱職的C++程序員來說是一個基本標準。想要做到這點，首先要了解語言中每個特性的實現(xiàn)方式及其開銷。本文主要討論相對于傳統(tǒng)C而言，對效率有影響的幾個C++新特性。
C++引入的額外開銷體現(xiàn)在以下兩方面：
編譯時開銷
| 模板、類層次結構、強類型檢查等新特性，以及大量使用了這些新特性的C++模板、算法庫都明顯地增加了C++編譯器的負擔。但是應當看到，這些新機能在不增加程序執(zhí)行效率的前提下，明顯降低了廣大C++程序員的工作量。
用幾秒鐘的CPU時間換取程序員幾小時的辛勤勞動，附帶節(jié)省了日后debug和維護代碼的時間，這點開銷當算超值。
當然，在使用這些特性的時候，也有不少優(yōu)化技巧。比如：編譯一個大型軟件時，幾條顯式實例化指令就可能使編譯速度提高幾十倍；恰當?shù)亟M合使用部分專門化和完全專門化，不但可以最優(yōu)化程序的執(zhí)行效率，還可以讓同時使用多種不同參數(shù)實例化模板的軟件體積顯著減小……
|
運行時開銷
運行時開銷恐怕是程序員最關心的問題之一了。相對與傳統(tǒng)C程序而言，C++中有可能引入額外運行時開銷的新特性包括：
- 虛基類
- 虛函數(shù)
- RTTI（dynamic_cast和typeid）
- 異常
- 對象的構造和析構
關于其中第四點 異常，對于幾乎所有的現(xiàn)代編譯器來說，在正常情況（未拋出異常）下，try塊中的代碼執(zhí)行效率和普通代碼一樣高，而且由于不再需要使用傳統(tǒng)上通過返回值或函數(shù)調用來判斷錯誤的方式，代碼的實際執(zhí)行效率還會進一步提高。拋出和捕捉異常的效率也只是在某些情況下會高于函數(shù)返回和函數(shù)調用的效率，何況對于一個編寫良好的程序，拋出和捕捉異常的機會應該不多。關于異常使用的詳細討論，參見：C++編碼規(guī)范正文。
而第五點對象的構造和析構開銷也不總是存在。對于不需要初始化/銷毀的類型，并沒有構造和析構的開銷，相反對于那些需要初始化/銷毀的類型來說，即使用傳統(tǒng)的C方式實現(xiàn)，也至少需要與之相當?shù)拈_銷。
對能夠真正用于開發(fā)的編譯器而言，C++本身就是使用C/匯編 加以千錘百煉的優(yōu)化才實現(xiàn)的。也就是說，想用C甚至匯編更高效地實現(xiàn)某個C++特性幾乎是不可能的。要是真能做到這一點的話，大俠就應該去寫個編譯器造福廣大程序員才對～
C++之所以比C“低效”，其根本原因在于：由于對某些特性的實現(xiàn)方式及其開銷不夠了解，導致程序員在錯誤的位置使用了錯誤的特性。而這些錯誤基本都集中在：
- 把異常當作另一種流程控制機制，而不是僅將其用于錯誤處理中
- 濫用或不正確地使用RTTI、虛函數(shù)和虛基類機制
其中第一點上文已經 講過，下面討論第二點。
為了說明RTTI、虛函數(shù)和虛基類的實現(xiàn)方式，首先給出一個實例及其具體實現(xiàn)（為了便于理解，這里故意忽略了一些無關緊要的優(yōu)化）：
|
圖中虛箭頭代表偏移，實箭頭代表指針
由上圖得到每種特性的運行時開銷如下：
| 特性 |
時間開銷 |
空間開銷 |
| RTTI |
幾次整形比較和一次取址操作（可能還會有1、2次整形加法） |
每類型一個type_info對象（包括類型ID和類名稱），典型情況下小于32字節(jié)
|
| 虛函數(shù) |
一次整形加法和一次指針引用 |
每類型一個虛表，典型情況下小于32字節(jié)
每對象若干個（大部分情況下是一個）虛表指針，典型情況下小于8字節(jié)
|
| 虛基類 |
從直接虛繼承的子類（例如上圖中的 "B1" 和 "B2"，但不包括 "DD" ）中訪問虛基類的數(shù)據(jù)成員或其虛函數(shù)時，將增加兩次指針引用（大部分情況下可以優(yōu)化為一次）和一次整形加法。 |
每類型一個虛基類表，典型情況下小于16字節(jié)
每對象若干虛基類表指針，典型情況下小于8字節(jié)
|
| * 其中“每類型”或“每對象”是指用到該特性的類型/對象。對于未用到這些功能的類型及其對象，則不會增加上述開銷 |
可見，關于老天爺“餓時掉餡餅、睡時掉老婆”等美好傳說純屬謠言。但凡人工制品必不完美，總有設計上的取舍，有其適應的場合也有其不適用的地方。
C++中的每個特性，都是從程序員平時的生產生活中逐漸精化而來的。在不正確的場合使用它們必然會引起邏輯、行為和性能上的問題。對于上述特性，應該只在必要、合理的前提下才使用。
"dynamic_cast" 用于在類層次結構中漫游，對指針或引用進行自由的向上、向下或交叉強制。"typeid" 則用于 獲取一個對象或引用的確切類型，與 "dynamic_cast" 不同，將 "typeid" 作用于指針通常是一個錯誤， 要得到一個指針指向之對象的type_info，應當先將其解引用（例如：typeid(*p)）。
一般地講，能用虛函數(shù)解決的問題就不要用 "dynamic_cast"，能夠用 "dynamic_cast" 解決的就不要用 "typeid"。比如：
void
rotate(IN const CShape& iS)
{
if (typeid(iS) == typeid(CCircle))
{
// ...
}
else if (typeid(iS) == typeid(CTriangle))
{
// ...
}
else if (typeid(iS) == typeid(CSqucre))
{
// ...
}
// ...
} |
以上代碼用 "dynamic_cast" 寫會稍好一點，當然最好的方式還是在其中每個類里定義名為 "rotate" 的虛函數(shù)。
虛函數(shù)是C++運行時多態(tài)特性中開銷最小，也最常用的機制。虛函數(shù)的好處和作用這里不再多說，應當注意在對性能有苛刻要求的場合，或者需要頻繁調用，對性能影響較大的地方（比如每秒鐘 要調用上百次的事件處理函數(shù)）要慎用虛函數(shù)。
作為一種支持多繼承的面向對象語言，虛基類有時是保證類層次結構正確的一種必不可少的手段。在需要頻繁使用基類提供的服務，又對性能要求較高的場合，應該避免使用虛基類。
在基類中沒有數(shù)據(jù)成員的場合，也可以解除使用虛基類。例如，在上圖中，如果類 "BB" 中不存在數(shù)據(jù)成員，那么 "BB" 就可以作為一個普通基類分別被 "B1" 和 "B2" 繼承。這樣的優(yōu)化在達到相同效果的前提下，解除了虛基類引起的開銷。不過這種優(yōu)化也會帶來一些問題：從 "DD" 向上強制到 "BB" 時會引起歧義；破壞了類層次結構的邏輯關系。
上述特性的空間開銷一般都是可以接受的，當然也存在一些特例，比如：在存儲布局需要和傳統(tǒng)C結構兼容的場合、在考慮對齊的場合、在需要為一個本來很小的類同時實例化許多對象的場合等等。
|
