1，typedef不必要？
a，typedef提供了一層間接，面向對象語言中，接口掩蓋了運行時不同具體類型間的差別，而typedef掩蓋了編譯時不同類型間的差別，卻又不喪失類型安全性
b，一般語言只能返回“值”，而typedef提供了返回“類型”的能力，這是模板元編程不可或缺的機制，除非模板元編程眼下也是不必要的
2，導入
在不同地點分別對#include，private成員放在頭文件中，inline函數也放在頭文件中進行了批判，實際上原因只有一個：C++不是
平臺，它沒有二進制標準，它編譯后成為本地代碼，喪失了一切類型信息；只有解決了這個問題，才能解決跟分發重用導入相關的各種問題
3，引用是多余的？會被破壞？
a，資源釋放問題引用比指針更明確，即提供原始對象一方負責釋放資源，而一旦用指針做接口參數，就需要約定誰來釋放資源
b，空引用在well-formed的程序中是不存在的，因為產生它的唯一方式是提領空指針，而提領空指針是未定義的行為，程序很快就會出錯，而不是像被破壞的指針一樣，有些運算出錯，有些不出，有時出錯，有時不出
C99也加入了對引用的支持
4，直接重復繼承
C++缺乏Eiffel擁有的“直接重復繼承”機制，但假如有的話，語義是什么呢？沒看過Eiffel，不懂
5，多重繼承
論述較為精辟，對多重處理的繼承是C++的軟肋，Java禁止了多重實現繼承，但提供的“單實現繼承+多接口繼承+內部類”卻又缺乏靈活性和直觀性
6，內部類破壞面向對象？破壞復用性？
有失公允，除非面向對象排斥面向接口，復用僅止源代碼復用；1，內部類提供更好的封裝性；2，內部類經過簡單包裝后可以以可執行代碼的形式提供面向接口的復用，一個例子是“List Collections.unmodifiedList(List)”，可用內部類優雅的實現(不知實際實現如何)
7，virtual/override
C++與C#的做法給了基類作者巨大的責任，而這些本應子類作者承擔；包括C++里的虛基類，子類的變化迫使父類作出改動
8，虛擬類型
文中說C++只提供了參數化類，沒提供虛擬類型，可從所舉的虛擬類型的例子來看，似乎用前文所鄙視的typedef即可完成，不知是否如此.
9，束縛多態
在C++里一般稱為模板參數約束，正考慮加入下版標準；但如果只是用在書中所舉例子，模板參數約束為實現某個接口，那么用接口做為參數就可以了，為什么還要泛型呢？泛型表達了一種Concept，泛參檢查也應該為Concept Check，而不是Type Check
10，訪問控制
Eiffel對子類訪問權限不加限制只能算是一個特性，未必是優點；基于對復用的兩種不同理解和側重，C++和Eiffel選擇了對待子類的兩種不同態度；對C++私有繼承批評時所舉的例子并不恰當，造成問題的根源是強制轉型，而不是私有繼承
11，展開對象
對“.”和“->”的批評太孤立了，實際上“->”是可重載的操作符，提供了一層間接，利用這層間接可以做很多事情：資源管理，以包容的方式獲得繼承的便利（自動“擁有”被包容對象的方法）等等；Eiffel提供了“展開對象”，不知具體語義如何
12，直接重復繼承
翻到這里才看到了Eiffel中直接重復繼承的一種用處：原來是為了在子類中調用父類同名方法；隨著Precursor加入語言，這種用法也可以被拋棄了
13，抗變與協變
返回值協變似乎沒多大問題，參數抗變似乎也沒多大問題，問題在于參數協變；Eiffel提供了Current和like來解決，C++只能期待受束泛型了
14，強制針對接口編程
作者認為父類中的public成員在子類中重定義時改為protected或private會帶來協變問題，其實只要重定義函數的語義正確，也沒什
么；而且這種變化會帶來另外一種效果：強制針對接口編程；因為此時你的客戶程序員只能通過父類來引用你的子類對象才能訪問重定義的成員
15，垃圾收集
還是那些話題，還是那些論調，還是對內存外的資源管理避而不談；難道不能“析構函數＋棧對象＋堆對象垃圾收集”？C++只不過缺省缺少“堆對象垃圾收集”，智能指針還能撐一會，Java和Eiffel則缺少“棧對象＋析構函數”
16，契約式設計與CORBA IDL
作者認為CORBA IDL不支持契約式設計是一個缺陷，可我從來不敢在我的DCOM，RMI，.Net
Remoting組件中使用斷言，包括最初的socket
server；這可是暴露在網絡環境中啊，違反前置條件是要拋異常的啊；WebService稍好一點，明確定義了異常處理，有中間件支持