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