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