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