用幾秒鐘的CPU時(shí)間換取幾人日的辛勤勞動(dòng)，附帶節(jié)省了日后調(diào)試和維護(hù)代碼的時(shí)間，這點(diǎn)開銷當(dāng)算超值。

當(dāng)然，在使用這些特性的時(shí)候，也有不少優(yōu)化技巧。比如：編譯一個(gè) 廣泛依賴模板庫(kù)的大型軟件時(shí)，幾條顯式實(shí)例化指令就可能使編譯速度提高幾十倍；恰當(dāng)?shù)亟M合使用部分專門化和完全專門化，不但可以最優(yōu)化程序的執(zhí)行效率，還可以讓同時(shí)使用多種不同參數(shù)實(shí)例化一套模板的程序體積顯著減小……

1. 虛基類
2. 虛函數(shù)
3. RTTI（dynamic_cast和typeid）
4. 異常
5. 對(duì)象的構(gòu)造和析構(gòu)

關(guān)于其中第四點(diǎn)：異常，對(duì)于大多數(shù)現(xiàn)代編譯器來(lái)說(shuō)，在正常情況（未拋出異常）下，try塊中的代碼執(zhí)行效率和普通代碼一樣高，而且由于不再需要使用傳統(tǒng)上通過(guò)返回值或函數(shù)調(diào)用來(lái)判斷錯(cuò)誤的方式，代碼的實(shí)際執(zhí)行效率還可能進(jìn)一步提高。拋出和捕捉異常的效率也只是在某些情況下才會(huì)稍低于函數(shù)正常返回的效率，何況對(duì)于一個(gè)編寫良好的程序，拋出和捕捉異常的機(jī)會(huì)應(yīng)該不多。關(guān)于異常使用的詳細(xì)討論，參見：C++編碼規(guī)范正文中的相關(guān)部分和C++異常機(jī)制的實(shí)現(xiàn)方式和開銷分析一節(jié)。

而第五點(diǎn)，對(duì)象的構(gòu)造和析構(gòu)開銷也不總是存在。對(duì)于不需要初始化/銷毀的類型，并沒(méi)有構(gòu)造和析構(gòu)的開銷，相反對(duì)于那些需要初始化/銷毀的類型來(lái)說(shuō)，即使用傳統(tǒng)的C方式實(shí)現(xiàn)，也至少需要與之相當(dāng)?shù)拈_銷。這里要注意的一點(diǎn)是盡量不要讓構(gòu)造和析構(gòu)函數(shù)過(guò)于臃腫，特別是在一個(gè)類層次結(jié)構(gòu)中更要注意。時(shí)刻保持你的構(gòu)造、析構(gòu)函數(shù)中只有最必要的初始化和銷毀操作，把那些并不是每個(gè)（子）對(duì)象都需要執(zhí)行的操作留給其他方法和派生類去解決。

其實(shí)對(duì)一個(gè)優(yōu)秀的編譯器而言，C++的各種特性本身就是使用C/匯編加以千錘百煉而最優(yōu)化實(shí)現(xiàn)的。可以說(shuō)，想用C甚至匯編比編譯器更高效地實(shí)現(xiàn)某個(gè)C++特性幾乎是不可能的。要是真能做到這一點(diǎn)的話，大俠就應(yīng)該去寫個(gè)編譯器造福廣大程序員才對(duì)～

C++之所以 被廣泛認(rèn)為比C“低效”，其根本原因在于：由于程序員對(duì)某些特性的實(shí)現(xiàn)方式及其產(chǎn)生的開銷不夠了解，致使他們?cè)阱e(cuò)誤的場(chǎng)合使用了錯(cuò)誤的特性。而這些錯(cuò)誤基本都集中在：

• 把異常當(dāng)作另一種流控機(jī)制，而不是僅將其用于錯(cuò)誤處理中
• 一個(gè)類和/或其基類的構(gòu)造、析構(gòu)函數(shù)過(guò)于臃腫，包含了很多非初始化/銷毀范疇的代碼
• 濫用或不正確地使用RTTI、虛函數(shù)和虛基類機(jī)制

其中前兩點(diǎn)上文已經(jīng)講過(guò)，下面討論第三點(diǎn)。

為了說(shuō)明RTTI、虛函數(shù)和虛基類的實(shí)現(xiàn)方式，這里首先給出一個(gè)經(jīng)典的菱形繼承實(shí)例，及其具體實(shí)現(xiàn)（為了便于理解，這里故意忽略了一些無(wú)關(guān)緊要的優(yōu)化）：

可見，關(guān)于老天“餓時(shí)掉餡餅、睡時(shí)掉老婆”等美好傳說(shuō)純屬謠言。但凡人工制品必不完美，總有設(shè)計(jì)上的取舍，有其適應(yīng)的場(chǎng)合也有其不適用的地方。

C++中的每個(gè)特性，都是從程序員平時(shí)的生產(chǎn)生活中逐漸精化而來(lái)的。在不正確的場(chǎng)合使用它們必然會(huì)引起邏輯、行為和性能上的問(wèn)題。對(duì)于上述特性，應(yīng)該只在必要、合理的前提下才使用。

"dynamic_cast" 用于在類層次結(jié)構(gòu)中漫游，對(duì)指針或引用進(jìn)行自由的向上、向下或交叉強(qiáng)制。"typeid" 則用于獲取一個(gè)對(duì)象或引用的確切類型，與 "dynamic_cast" 不同，將 "typeid" 作用于指針通常是一個(gè)錯(cuò)誤，要得到一個(gè)指針指向之對(duì)象的type_info，應(yīng)當(dāng)先將其解引用（例如："typeid(*p);"）。

一般地講，能用虛函數(shù)解決的問(wèn)題就不要用 "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" 寫會(huì)稍好一點(diǎn)，當(dāng)然最好的方式還是在CShape里定義名為 "rotate" 的虛函數(shù)。

虛函數(shù)是C++眾多運(yùn)行時(shí)多態(tài)特性中開銷最小，也最常用的機(jī)制。虛函數(shù)的好處和作用這里不再多說(shuō)，應(yīng)當(dāng)注意在對(duì)性能有苛刻要求的場(chǎng)合，或者需要頻繁調(diào)用，對(duì)性能影響較大的地方（比如每秒鐘要調(diào)用成千上萬(wàn)次，而自身內(nèi)容又很簡(jiǎn)單的事件處理函數(shù)）要慎用虛函數(shù)。

需要特別說(shuō)明的一點(diǎn)是：虛函數(shù)的調(diào)用開銷與通過(guò)函數(shù)指針的間接函數(shù)調(diào)用（例如：經(jīng)典C程序中常見的，通過(guò)指向結(jié)構(gòu)中的一個(gè)函數(shù)指針成員調(diào)用；以及調(diào)用DLL/SO中的函數(shù)等常見情況）是相當(dāng)?shù)摹１绕鸷瘮?shù)調(diào)用本身的開銷（保存現(xiàn)場(chǎng)->傳遞參數(shù)->傳遞返回值->恢復(fù)現(xiàn)場(chǎng)）來(lái)說(shuō)，一次指針間接引用是微不足道的。這就使得在絕大部分可以使用函數(shù)的場(chǎng)合中都能夠負(fù)擔(dān)得起虛方法的些微額外開銷。

作為一種支持多繼承的面向?qū)ο笳Z(yǔ)言，虛基類有時(shí)是保證類層次結(jié)構(gòu)正確一致的一種必不可少的手段。但在需要頻繁使用基類提供的服務(wù)，又對(duì)性能要求較高的場(chǎng)合，應(yīng)該盡量避免使用它。在基類中沒(méi)有數(shù)據(jù)成員的場(chǎng)合，也可以解除使用虛基類。例如，在上圖中，如果類 "BB" 中不存在數(shù)據(jù)成員，那么 "BB" 就可以作為一個(gè)普通基類分別被 "B1" 和 "B2" 繼承。這樣的優(yōu)化在達(dá)到相同效果的前提下，解除了虛基類引起的開銷。不過(guò)這種優(yōu)化也會(huì)帶來(lái)一些問(wèn)題：從 "DD" 向上強(qiáng)制到 "BB" 時(shí)會(huì)引起歧義，破壞了類層次結(jié)構(gòu)的邏輯關(guān)系。

上述特性的空間開銷一般都是可以接受的，當(dāng)然也存在一些特例，比如：在存儲(chǔ)布局需要和傳統(tǒng)C結(jié)構(gòu)兼容的場(chǎng)合、在考慮對(duì)齊的場(chǎng)合、在需要為一個(gè)本來(lái)尺寸很小的類同時(shí)實(shí)例化許多對(duì)象的場(chǎng)合等等。