=================================================================
轉載鏈接： http://www.baiy.cn/doc/cpp/inside_rtti.htm
“在正確的場合使用恰當的特性” 對稱職的C++程序員來說是一個基本標準。想要做到這點，首先要了解語言中每個特性的實現方式及其開銷。本文主要討論相對於傳統 C 而言，對效率有影響的幾個C++新特性：
相對於傳統的 C 語言，C++ 引入的額外開銷體現在以下兩個方面：
編譯時開銷
![]()
| 模板、類層次結構、強類型檢查等新特性，以及大量使用了這些新特性的 STL 標準庫都增加了編譯器負擔。但是應當看到，這些新機能在不降低，甚至（由於模板的內聯能力）提升了程序執行效率的前提下，明顯減輕了廣大 C++ 程序員的工作量。 用幾秒鐘的CPU時間換取幾人日的辛勤勞動，附帶節省了日後調試和維護代碼的時間，這點開銷當算超值。 當然，在使用這些特性的時候，也有不少優化技巧。比如：編譯一個 廣泛依賴模板庫的大型軟件時，幾條顯式實例化指令就可能使編譯速度提高几十倍；恰當地組合使用部分專門化和完全專門化，不但可以最優化程序的執行效率，還可以讓同時使用多種不同參數實例化一套模板的程序體積顯著減小…… |
運行時開銷
![]()
運行時開銷恐怕是程序員最關心的問題之一了。相對與傳統C程序而言，C++中有可能引入額外運行時開銷的新特性包括：
關於其中第四點：異常，對於大多數現代編譯器來說，在正常情況（未拋出異常）下，try塊中的代碼執行效率和普通代碼一樣高，而且由於不再需要使用傳統上通過返回值或函數調用來判斷錯誤的方式，代碼的實際執行效率還可能進一步提高。拋出和捕捉異常的效率也只是在某些情況下才會稍低於函數正常返回的效率，何況對於一個編寫良好的程序，拋出和捕捉異常的機會應該不多。關於異常使用的詳細討論，參見：C++編碼規範正文中的相關部分和C++異常機制的實現方式和開銷分析一節。 而第五點，對象的構造和析構開銷也不總是存在。對於不需要初始化/銷燬的類型，並沒有構造和析構的開銷，相反對於那些需要初始化/銷燬的類型來說，即使用傳統的C方式實現，也至少需要與之相當的開銷。這裏要注意的一點是儘量不要讓構造和析構函數過於臃腫，特別是在一個類層次結構中更要注意。時刻保持你的構造、析構函數中只有最必要的初始化和銷燬操作，把那些並不是每個（子）對象都需要執行的操作留給其他方法和派生類去解決。 其實對一個優秀的編譯器而言，C++的各種特性本身就是使用C/彙編加以千錘百煉而最優化實現的。可以說，想用C甚至彙編比編譯器更高效地實現某個C++特性幾乎是不可能的。要是真能做到這一點的話，大俠就應該去寫個編譯器造福廣大程序員纔對～ C++之所以 被廣泛認爲比C“低效”，其根本原因在於：由於程序員對某些特性的實現方式及其產生的開銷不夠了解，致使他們在錯誤的場合使用了錯誤的特性。而這些錯誤基本都集中在：
其中前兩點上文已經講過，下面討論第三點。 爲了說明RTTI、虛函數和虛基類的實現方式，這裏首先給出一個經典的菱形繼承實例，及其具體實現（爲了便於理解，這裏故意忽略了一些無關緊要的優化）： |
圖中虛箭頭代表偏移，實箭頭代表指針
由上圖得到每種特性的運行時開銷如下：
可見，關於老天“餓時掉餡餅、睡時掉老婆”等美好傳說純屬謠言。但凡人工製品必不完美，總有設計上的取捨，有其適應的場合也有其不適用的地方。 C++中的每個特性，都是從程序員平時的生產生活中逐漸精化而來的。在不正確的場合使用它們必然會引起邏輯、行爲和性能上的問題。對於上述特性，應該只在必要、合理的前提下才使用。 "dynamic_cast" 用於在類層次結構中漫遊，對指針或引用進行自由的向上、向下或交叉強制。 "typeid" 則用於獲取一個對象或引用的確切類型，與 "dynamic_cast" 不同，將 "typeid" 作用於指針通常是一個錯誤，要得到一個指針指向之對象的type_info，應當先將其解引用（例如："typeid(*p);"）。 一般地講，能用虛函數解決的問題就不要用 "dynamic_cast"，能夠用 "dynamic_cast" 解決的就不要用 "typeid"。比如：
以上代碼用 "dynamic_cast" 寫會稍好一點，當然最好的方式還是在CShape裏定義名爲 "rotate" 的虛函數。 虛函數是C++衆多運行時多態特性中開銷最小，也最常用的機制。虛函數的好處和作用這裏不再多說，應當注意在對性能有苛刻要求的場合，或者需要頻繁調用，對性能影響較大的地方（比如每秒鐘要調用成千上萬次，而自身內容又很簡單的事件處理函數）要慎用虛函數。 需要特別說明的一點是：虛函數的調用開銷與通過函數指針的間接函數調用（例如：經典C程序中常見的，通過指向結構中的一個函數指針成員調用；以及調用DLL/SO中的函數等常見情況）是相當的。比起函數調用本身的開銷（保存現場->傳遞參數->傳遞返回值->恢復現場）來說，一次指針間接引用是微不足道的。這就使得在絕大部分可以使用函數的場合中都能夠負擔得起虛方法的些微額外開銷。 作爲一種支持多繼承的面嚮對象語言，虛基類有時是保證類層次結構正確一致的一種必不可少的手段。但在需要頻繁使用基類提供的服務，又對性能要求較高的場合，應該儘量避免使用它。在基類中沒有數據成員的場合，也可以解除使用虛基類。例如，在上圖中，如果類 "BB" 中不存在數據成員，那麼 "BB" 就可以作爲一個普通基類分別被 "B1" 和 "B2" 繼承。這樣的優化在達到相同效果的前提下，解除了虛基類引起的開銷。不過這種優化也會帶來一些問題：從 "DD" 向上強制到 "BB" 時會引起歧義，破壞了類層次結構的邏輯關係。 上述特性的空間開銷一般都是可以接受的，當然也存在一些特例，比如：在存儲佈局需要和傳統C結構兼容的場合、在考慮對齊的場合、在需要爲一個本來尺寸很小的類同時實例化許多對象的場合等等。 ================================================================= 冷靜思考，勇敢面對，把握未來！！！ ================================================================= | ||||||||||||||||
