閎約深美Ｃ＋＋

王海鵬

大約在1993年的時候，我開始學習C++。C++是我的“初戀情人”。雖然之前也學過Basic和Fortran，但只是作為學校里的一門課程來學的；而C++則是伴我度過青澀成長歲月的編程語言。那時候國內C++的書籍還非常少，對我影響最大的是《Borland C++ 3.0程序員指南》。近年來一直在用Java，算算時間，沒有關心C++也有五六年了，期間C++出了新標準，我也是知之不詳。前些日子朋友送來一本《C++編程思想》（第2卷），正好趁此機會重學一遍。

這本書的第一部分主題是構建穩定的系統。初級程序員往往只考慮功能需求，而高級程序員將考慮更多的東西，包括健壯性、性能、可伸縮性、可維護性、可擴展性等。構建穩定的系統就是功能之外首先值得考慮的東西。

作為一名Java程序員，我已經能熟練使用，深知在軟件開發中，對發生概率較小的異常情況的處理可能會占掉相當多的思考時間。而這反映在健壯軟件的代碼中，就是有相當多的異常處理代碼。只是當年學習使用C++時，對軟件開發的理解還比較淺，對異常的處理接觸得相對也比較少。在C++中，基本數據類型（如int）也可以拋出，不像Java，只能拋出實現了Throwable接口的對象。在C++的try…catch語句中，特別要注意資源釋放的問題，Java亦是如此。

auto_ptr是為簡化C++資源（特別是內存）管理問題而提供的一種機制，書中通過一個簡化的版本說明了auto_ptr的原理。這里用到了模板。模板實現了另一種抽象層面的復用，有時候它的作用類似于宏。具體到“資源獲得式初始化（RAII）”，如果擁有資源的對象在超出其作用域時都需要釋放其資源，那么何不把這種行為集中實現？函數模板和通用算法也是如此。這樣做的結果是消除了重復，減少了代碼量。這就是auto_ptr的設計動機。

不像Java，C++沒有垃圾回收機制，所以C++程序員必須投入更多的精力來思考資源分配/釋放問題。如果某件事（如釋放內存）總是被忘記，那就設計一種機制來防止再次忘記。總結起來，在C++中使用對象或分配內存，有以下兩個原則：（1）盡量在棧中分配對象；（2）如果要使用堆，就使用auto_ptr模板類。

要理解auto_ptr，需要程序員理解棧和堆、動態內存分配、棧反解、構造函數和析構函數的調、模板等概念。雖然也可以死記住這種用法，但說不準哪天就會帶來大麻煩。例如Java雖然有GC，但OutOFMemory的異常還是屢見不鮮。這就是知其然而不知其所以然的問題。C++對程序員提出了較高的要求，對PC結構和內存管理，結構化編程和面向對象編程都要有相當的理解。所以網上有人說：“真正的程序員使用C++。”

書中提到，雖然可以在方法聲明中聲明該方法可能會拋出的異常，但是標準C++庫中的函數卻都沒有這樣做。原因是當模板與具體類綁定時，異常類型可能是未知的。作者通過這一點告訴我們，雖然語言提供了某種機制，用還是不用，完全取決于使用者。

要構建健壯的系統，就不能不提防御式編程。這個概念與契約式編程有關，強調程序單元有清晰的規格說明，并在錯誤發生的第一地點發現它，避免因為“垃圾進，垃圾出”而引發不可知的嚴重后果。Meyer的“面向對象軟件構造”對此有深入論述，這是嚴謹的OO程序員必須學習和理解的內容。有人把契約式編程理解為一種責任劃定，出了問題的時候可以確定到底是哪個程序員的責任，所以可以假定別人都實現了契約，而不必再寫代碼進行檢查。筆者認為這樣的理解是有偏差的。難道與人簽訂了合同之后就不用檢查合同履行的情況？契約式編程的目的是為了得到更健壯的系統，所以直接導致了防御式編程。

單元測試用于檢查一個程序單元對它的契約（規格說明）執行的情況。大致可以分為兩部分工作：（1）如果調用者不能滿足前置條件，程序是否能正確反應；（2）在調用者滿足前置條件的情況下，程序是否確保了后置條件的成立，并給出了預期的結果。讓設計變成可測試的規格說明，讓測試可以自動進行。書中第2章還介紹了一個極為精簡的測試框架，只包含兩個類。用最少的代碼來實現你的意圖，體現了簡約之美。少即是多。如果讀者對單元測試想了解更多，可以去看Kent Beck的《測試驅動開發》和其他一些書籍。熟悉JUnit的讀者則可以體會一下，用不同的語言來表述同樣的思想時的差異。

書中利用宏實現了調試時的代碼跟蹤。宏的運用對于C程序員應該不陌生，Java程序員則需要多花一些時間來體會。

調試和內存泄漏檢查，都是C++程序員不能回避的話題。書中簡單介紹了兩個基本方法，雖然詳細討論這兩個問題需要更大的篇幅，而且在實際工作中可能會采用BoundsChecker或Purify這樣的工具，但這種簡單的方法比較有利于初次接觸這個領域的人理解概念，也容易進行嘗試。

第二部分的主題是標準C++庫。面向對象系統通過復用來提高開發效率，標準庫則是實現復用的一個重要方面。作為一個Java程序員，筆者對這一點深有體會。

以前用Borland C++時，筆者也用過String類，但那不屬于C++標準，是廠商擴展。學過C的人都知道，使用C的char*或char[]需要專門的練習。C++則利用對象封裝的力量，減輕了程序員的負擔。Java有String和StringBuffer兩個類，它們在實現原理上不同，適用的場合也不同，《Effective Java》一書中有詳細討論。C++只有string類，關于它的對象創建和內存管理可以仔細研究一下，這涉及效率。首先考慮效率問題，是C/C++文化的“商標”。要考慮效率，就需要對計算機的結構和工作原理有充分的了解。一個深受C/C++文化影響的人，會不由自主地考慮每條語句后面計算機所做的事，并考慮這樣做是否有效率，而許多只學過Java的程序員則很難表現出這一特點。不過遺憾的是書中沒有附帶介紹正則表達式的使用，以筆者的經驗，正則表達式是字符串操作的有力工具。

抽象出流的概念是面向對象設計的又一經典范例，向我們展現了一個好的對象系統設計是多么易于理解。Java也繼承了這一概念，雖然實現上有差異。通過從istream和ostream多繼承得到iostream，這和十多年前筆者學到的一樣，只是現在這些類都已模板化，并成為了C++標準的一部分。對國際化和本地化的支持也是現代編程語言不可缺少的特征，今天的C++對寬字符也有了良好支持，處理漢字時不再像當年那么麻煩了。

模板的威力令人印象深刻，C++標準中的許多東西都已構架在模板的基礎上了，如string、auto_ptr、IO流和bitset等。C++社區對模板有著特殊濃厚的興趣。從C++開始引入模板至今，大家想出了各式各樣的精巧用法，甚至有“模板元編程”這樣的奇特用法。Java也在1.5版本中引入了模板泛型編程。

模板的使用也產生了些許問題。模板對編譯器帶來了相當的負擔，尤其惱人的是在編譯時難以提供準確的出錯信息。另外，大量使用模板的程序也向閱讀者提出了更高的要求（請嘗試讀一下STL的源代碼）。一些專家建議慎用模板，例如在《UML參考手冊》（第2版）的Template詞條中指出：“模板應該慎用。在許多時候（如在C++中），它們完成的功能可以通過多態和泛化更好地實現，使用模板只是基于一種追求不必要的效率的錯誤的熱情。因為它們是生成器，它們的結果并不總是顯而易見的。”

模板為開發者提供了這樣一種場景，即我定義了一個通用算法，歡迎您來使用它；我定義了一個參數化類，歡迎您來特化它。往深了說，這涉及面向對象哲學：有沒有純粹的算法？有沒有純粹的數據？世界僅僅是由對象和行為組成，還是存在超越對象而獨立存在的法則，這些法則對許多類對象都有效？C++標準的設計者認為這種法則是存在的，所以在設計中實現了通用算法。而在Java中，即使存在這種法則，也要放在某個Util類或靜態方法里去，寫成God.newtonRuleOne()這種樣子。這種做法讓不少Java程序員在理解Singleton或service oriented programming時存在困難，在使用Spring這樣的框架時也感到別扭。理解C++標準庫時，也需要了解一點“C++哲學”。

容器類非常重要，所以人們一遍又一遍地實現它。《Borland C++ 3.0程序員指南》中就提到它提供了兩個容器類，其中一個是基于模板技術實現的。Java在提供泛型支持后，又重寫了容器類的代碼，而在此前，容器類已經由著名的Joshua Bloch重寫了一遍。C++的容器類實現完整，有dequeue、stack、bitset這樣的類。流迭代器也是Java中沒有的概念。筆者感覺，C++中的迭代器概念更像“封裝過的指針”。

與Java SDK中提供的類和方法相比，C++的標準庫還是比較小的。但網上有不少C++的庫可用，只是沒有像Java那樣形成標準。BOOST是一個“半官方”性質的C++類庫，試想C++標準的制定者們一定也在考慮，有哪些東西值得放進C++標準庫中。

書中第三部分討論了一些擴展主題，在實際工作中碰到的機率也比較大。

RTTI是“反OO”的。在JUnit框架中，通過使用反射機制，提供了一種“非OO”的擴展方式，即TestCase子類中所有以“test”開頭的方法都會被框架當作測試執行。Xstream通過反射，可以訪問傳入參數中的私有屬性。在一個方法中，可以利用RTTI對傳入參數進行類型檢查，然后用switch語句對具體類型進行分別處理，從而導致沒有擴展性的設計，即犧牲了OO的多態性。然而，為了達到特殊的目的，您可以考慮這種犧牲。另外，使用RTTI也可能影響性能。設計即折衷。

多重繼承屬于那種聽起來很美的概念，要在自已的設計中使用多繼承，一不小心就會帶來許多麻煩。所以Java中沒有多繼承。在C++中，筆者也會考慮使用純虛類來實現類似Java接口的概念，這樣能避免多繼承的諸多問題。

設計模式已經成為一個職業程序員必須掌握的知識。書中提供了關于設計模式的一些擴展討論。讀這部分內容之前，最好已經研讀過那本經典的《設計模式》。

有人斷言，并發是自OO以來程序員應該掌握的重要概念。因為CPU主頻的增長已經遇到了“天花板”，CPU廠商紛紛推出多處理器系統或多內核系統來提高CPU的能力。為什么要在程序中使用并發？因為：（1）CPU要等待IO，特別是網絡IO；（2）我們要充分利用SMP、Dual Core和Quad的能力。第一點還能通過異步IO來解決，第二點就能只能靠并發了。在Java中，一開始就提供了多線程支持，在1.5版本中更是增加了最初由Doug Lea設計的并發包。在頭腦中建立起并發程序設計的概念是不容易的，所以線程安全和synchronized關鍵字一直是檢驗Java程序員水平的試金石。Bruce Eckel他們也認識到了并發程序設計的重要性，只是在C++標準中還沒有對并發的支持。書中通過一個開源的Zthread項目，介紹了并發編程的一些內容。

學習一門語言時，掌握其語法只是一部分工作，更值得關注的是熟練使用這種語言的人們如何運用語言的元素來表達他們的思想。與語法相比，一些習語和典故才是語言中更具魅力的部分。這本書在有限的篇幅內，向我們展示了C++社區的人們是如何使用C++的。

C++可能是最難學的編程語言之一，要學好它，需要講究方法。筆者曾經認真思考過語言學習的奧秘，最后得到的秘訣是八個字：聽說領先，讀寫跟上。對于自然語言的學習和編程語言的學習都是如此。聽、讀就是學習已經掌握這門語言的人如何使用它，說、寫就是自己實踐。“吾嘗終日而思矣，不如須臾之所學也。”Scott Ambler曾在他的著作《過程模式》中介紹過學習一門語言的方法：效率最高的方法是找到一個有資質的老師，參加他的課程；其次是找到一本好的教材，自己系統地學習；效率最低的方法是不看書，自己拿一個試驗項目開始折騰。

這本書的中文版翻譯質量比較好，但也存在一些瑕疵，如在講解派生類的契約時將“Require no more；promise no less”譯成了“不要只索取不付出”，筆者認為譯成“要求不能多，承諾不能少”更合適。又如第10章中“四人幫”的譯法，值得商榷。譯文總體上意思準確，語句通順，不會影響閱讀。

總之，這本書既適合作為初學者學習C++的教材，也適合像筆者這樣想了解C++新規范的人。在內容處理上符合本書的定位：一本C++培訓教材。如果說“在任何領域，讀5本書入門，讀50本書成為專家”，那么這本書可以列入5本書的范圍之內，當然也能成為50本書之一。

C++兼容并蓄，C++力求簡約，C++博大精深，C++有特殊的美，所以說：閎約深美C++。筆者看到C++從Java的發展中吸收了經驗，在下一個標準版本中，肯定會帶來更多的東西。筆者也希望有一天能有機會再用C++寫東西。