關(guān)于程序設(shè)計(jì)語言本身的設(shè)計(jì)有許多有趣的話題，比如，為何C++中的類成員函數(shù)沒有采用類似Java中的“全虛”設(shè)計(jì)？
1) 從語言本身設(shè)計(jì)上看，
效率定然是c++當(dāng)初設(shè)計(jì)時(shí)考慮的重點(diǎn)之一，舉個(gè)例子，為了節(jié)省不必要的VTable開銷，ATL用template技術(shù)靜態(tài)轉(zhuǎn)換來模擬動態(tài)綁定以支持COM特性的實(shí)現(xiàn)；和C的兼容，就VTable角度看，問題不大，因?yàn)楹笳呖梢杂煤瘮?shù)指針數(shù)組來模擬；
2) 再從大多數(shù)應(yīng)用中常見的類繼承體系上看，
除了整個(gè)繼承體系所統(tǒng)一開放出來的接口集（也就是由虛函數(shù)所組成），在繼承體系的每個(gè)層面另外會有大量的其他輔助成員函數(shù)（其數(shù)量通常比虛函數(shù)多的多），這些成員函數(shù)完全沒必要設(shè)計(jì)成虛函數(shù)；
3) 從其他語言看，
即使較新的虛擬機(jī)語言C#(Java算是較老的虛擬機(jī)語言),反而定義了比C++更為嚴(yán)格更為顯式的成員方法實(shí)現(xiàn)或覆蓋或重載或新建的規(guī)則；這是非常重要的對C++以及Java設(shè)計(jì)思想的反思。
4) 從語言的適用場合看，
我們現(xiàn)在的討論，絕大多數(shù)情況下帶有一個(gè)非常重要的默認(rèn)前提，那就是在用戶態(tài)模式下使用C++，如果放寬這個(gè)約束，在內(nèi)核模式下使用C++，那情況又完全不同了。
引用下面這個(gè)文檔的觀點(diǎn)，http://www.microsoft.com/china/whdc/driver/kernel/KMcode.mspx
首先，用戶態(tài)下非常廉價(jià)幾乎不用考慮的資源，在內(nèi)核中是非常昂貴的，比如內(nèi)核堆棧一般就3個(gè)page；
在內(nèi)核不能分頁(paging)時(shí)必須保證將被執(zhí)行的所有代碼和數(shù)據(jù)必須有效的駐留在物理內(nèi)存中，如果這時(shí)需要多駐留幾張?zhí)摫硪约疤摫碇羔樐沁€是顯得非常昂貴的，同時(shí)編譯器為虛函數(shù)，模板等生成代碼的方式，讓開發(fā)人員很難確定要執(zhí)行一個(gè)函數(shù)所需要的所有代碼的所在位置，因此也無法直接控制用于安置這些代碼的節(jié)（個(gè)人認(rèn)為可能通過progma segment/datasegment/codesegment對于代碼和數(shù)據(jù)進(jìn)行集中控制），因此在需要這些代碼時(shí)，可能已經(jīng)被page out了；
所有涉及類層次結(jié)構(gòu)，模板，異常等等這樣的一些語言結(jié)構(gòu)在內(nèi)核態(tài)中都可能是不安全的，最好是把類的使用限定為POD類，回到我們的主題虛函數(shù)，也就是說內(nèi)核態(tài)下類設(shè)計(jì)中沒有虛函數(shù)。