《Effective C++》讀後感

從八月初在噹噹上訂上這本書，到現在九月初把這本書粗粗讀完一遍，期間大概一個月時間，平均每天讀一個條款多一點。基本上，每個條款，除了個別的細節外，都能讀明白，大致上也都知道“所以然”。但是，如果現在讓我合上書，寫上一段代碼，恐怕這些理解還顯得膚淺——畢竟”看“和”寫“是兩碼事，程式員歸根結底還是要去”創造“的。

全書55個條款，可以看成55節，分為9章，作者的語言相對平實，思維有些跳躍，而且主要是以“問題”的形式去講述，有些章節還要再去翻《C++ Primer》這樣的書。侯捷的翻譯相對還算準確（大致感覺），有些翻譯有點拗口，有些也有些不恰當，這裡就不記了。

個人最感興趣的還是關於設計這三章（第4章：設計與聲明，第5章：實現，第6章，繼承與物件導向設計），這幾章淺顯易懂，讀起來也更流暢，最主要的還是當下手編程時非常實用。作者所提的關於虛函數的聲明，關於衍生類別中函數的重寫等等，都與這些內容緊密相關。

模板與泛型程式設計這一塊，以前從來沒有接觸過，只是知道模板的引入可以大大提高代碼的通用性，但是當作者指出C++模板系統可以當作一個圖靈機真的讓我驚豔了一把。得益於C++的命名系統，模板在編譯期的特化過程可以實現出分支與迴圈（遞迴）語句，給代碼的最終產生帶來了很大的靈活性。

當然，印象最深的，還是作者一遍又一遍苦口婆心地強調C++的命名規範和記憶體管理：前者，C++作為一個強型別語言，加上物件導向特性（類）的加入，使命名規範（包括類型轉換）成為一個難以理解更難於駕馭的特性；後者，作為繼承自C語言的能夠直接操作記憶體的語言，記憶體流失就像地雷一樣讓人防不勝防，以至於曆來的C++大牛們，花費了大量心血在防範記憶體配置錯誤這個問題上，設計出諸如智能指標、operator new甚至Boost程式庫中的pool。誠然，對於像Java和C#這樣的語言來講，記憶體配置只是個概念，虛擬機器會自動對程式實行“記憶體回收”，而C和C++這樣的手工管理方式雖然帶來了極高的運行效率和靈活性，同樣也帶來了極大的危險性。是的，從這方面來說，C++永遠是危險的，而C++程式員就如同在薄冰起舞。

關於C++與其他物件導向語言（如Java）孰優孰少的爭論由來已久，網上也時不時有人拿出來炒冷飯，而每次也都淪為雙方的口水戰，論點也都是一成不變的諸如效率的那些說辭。除去那些意氣之爭，大家都同意的看法是：對於一個“軟體開發人員”來說，Java或者C#就足夠了，程式員完全可以把自己的目光集中在軟體的外部行為上。論開發效率，兩者應該都比C++高，豐富的程式庫和設計更為精良的”物件導向體系“（不得不說C++在物件導向特性上表現得還有點原始）使得它們構建起一個方便快捷的生態系統；至於運行效率，對於一個普通的軟體來說，完全可以信任Java虛擬機器的設計者和硬體效能的提高。但是，對於“系統開發人員”來說，Java之流恐怕就有點力不從心了；另外，對於對效率要求得太高，以至於去逼近硬體發揮出最大潛力的程式，比如不斷推動PC硬體更新換代的電腦遊戲，比如支撐系統啟動並執行那些底層，比如包括Java虛擬機器這樣的“中介軟體“，C或者C++就是必須的了。

我從大二開始自學C++，研一時想重新拾起這個愛好深入學習電腦時，久久想如何選擇開發語言。我喜歡C++的”底層“屬性，這或許和我的物理專業背景有關，兩者都試圖從最基本的原理搭建出整個世界。不選擇C語言是因為在這個隨便編個程式就得幾百行的時代，用C寫程式太費勁了，缺乏”設計模式“和相對成熟的開發庫（Linux下倒是有一整套的開發架構，但是移植性不好）。我是從“介面編程”開始考慮的，如果一門語言或者開發架構連基本的圖形介面都難以產生，那就太不“實用”了。一開始想學微軟的VC++，從而看上了MFC架構，學了一段時間發現MFC其實是半C半C++的，而且架構相當混亂，網上說連微軟都不想支援這東西了，從而動力大減；這本書裡講了一個畫圖程式的實現例子，可是我跟著書寫了一個月，越寫越糊塗，寫到最後連自己都不知道這些函數為什麼要加進去，那些變數為什麼聲明得那麼繁瑣，還有哪裡來的幾十個又長又難懂的宏，從而徹底作罷。

這時我開始關注其他的C++開發架構，偶爾發現了Qt，它架構成熟，使用方便，同時移植性好，不僅能夠在Windows和Linux平台上遷移，甚至是嵌入式開發的不二人選。學上一段時間，發現它真的很適合我這樣一個沒有任何基礎的人。現在Qt的學習基本上已經入門，正在啃一些軟體開發的架構，有時間會將Qt的學習心得記在這裡。

網上列舉的C++學習書單，大致看來有這些，讀過的只有這本Effective C++和C++ Primer，計劃一本本讀完。