感慨：編寫堅固的代碼

    分析了公司的一個項目代碼，結果令我非常沮喪。分析的這個項目大約有500個檔案， 並不很大。我承認，這個項目的程式員都是訓練有素的，然而，都是C語言的訓練有素，不是C++的。
    我們為什麼選擇C++作為一個軟體項目的開發語言？我想，決不是因為C++更複雜華麗，也不是因為C++支援OO，OB，也決不是因為C++是支援GP的最佳選擇。論二進位相容性，C++不如C；論OO支援的乾淨利落，C++不如Java和C#-----C++太華麗和複雜；也許GP是一個不錯的選擇理由，但是，大部分程式員並沒有訓練有素地掌握GP。當然，我無法揣測別人為什麼會選擇C++，對我來說，選擇C++的理由只有兩個：1是C++的遺留項目，2是需要C++超群的表達力。
   然而，C++充滿了陷阱和習俗，恣意妄為的人必將受到懲罰。即使對於我這樣一個狂熱的技術跟風者而言，也沒有比寫堅固的代碼更重要的了----因為我首先是一個現實的軟體工程師。對於所有的C++程式員來說，也許沒有比《Effective C++》更重要的書了，每個C++程式員都應該熟讀此書。而今天，我們還有《C++編程規範》作為我們的編程指南，正像我曾經說過得那樣，值得我們將這101條貼在顯示器上每日誦讀．我願意不厭其煩地強調這兩本書，它們是所有打算用C++從事工程活動的程式員們的聖經。
   長期以來，我們一直沒有對代碼的安全性給予足夠的重視----MS的那套安全函數並非我所謂的安全的程式碼。我們必須把代碼的安全性提高到一個非常重要的程度：安全性是正確性的組成部分。也許這麼說是聳人聽聞，但是，我越來越堅信這個觀點是完全正確的。
    簡單的回顧一下項目中的嚴重缺陷。
    忽略了copy ctor和assignment的預設行為。在一個嵌入式引用計數的設計中，當對象被複製時，導致引用計數部分也被簡單複製，這很顯然是錯誤的。EC中強調過該如何注意copy ctor和default assignment，這樣的錯誤完全是可以避免的。
    引用計數，伴隨的當然是smart pointer的設計。必須認識到，編寫一個具有工業強度的smart pointer是非常有難度的，即使我們並不需要一個通用的設計，要實現一個專用的、足夠堅固和安全的smart pointer也不是一蹴而就的事情。有些問題，即使是boost::shared_ptr或者是Loki.SmartPtr這樣的實現也是有缺憾的----當然，也可能是我孤陋寡聞----如何?安全的const pointer?提供什麼樣的語義是最佳的?
    動態分配數組的問題.大量的new Type[size]...delete [] p;這樣的代碼。這樣的代碼如何保證異常安全性呢?大量的try...catch把代碼弄得一團糟.為什麼不用boost.scoped_array這樣的工具呢?即使不願意依賴第三方庫,實現一個簡易的scoped_array也不過十幾行代碼而已！
   回顧一下STL,必須成對的操作，有印象的大約只有allocator的4成員函數。所有的容器、演算法以及iostream家族，沒有必須成對操作的函數。事實上，擁有RAII這樣的利器，我們應該封裝幾乎所有的配對操作----竭盡全力！我所謂的配對操作是說那些必須成對執行，否則就不可能正確的操作，例如:new/delete, new[]/delete[]。
(continue)