C++沉思錄隨筆

話說書非借不能讀~~好象也有點道理，家裡買了好幾本書都一直以沒時間為由讀得不多，還有兩本被俺壓在坐位下面當墊子用了~~ 而事實上是並非時間不夠而是沒有善加利用罷了~~看來以後得改進一下. 正好同事借了一本C++沉思錄就隨手拿來看看，沒想到一發不過收拾，一口氣看完了，僅僅用了一天時間. 雖然是囫圇吞棗式的讀過來但還是大體領會了一些核心思想.

書是個老外寫的，具體啥名字記不得了，不過翻譯品質還不錯，沒有發現太多的語病. 讀起來也比較流暢. 好了，廢話不多說了，下面轉入正題.

電腦語言發展到C的時代已經比較後來的事情了，C語言作為一門優秀的電腦語言而被廣泛地使用著，然爾它在提供了足夠靈活強大的功能同時也帶來了不少的麻煩，最典型的要算是記憶體的分配與回收了，這個問題可以說是貫穿了本書的一個核心問題. 幾乎一切問題的根源均來源於此.  因為在C語言中程式員需要自己管理記憶體的使用，何時分配何時釋放就顯得特別重要，而C語言又引入了指標這麼一個概念，由此即可引發一系列的問題:

因為指標是指向某個記憶體位址的一個標識. 如果它指向的這個地址已經不再是指標本身限定的對象是就會引發不可知的後果造成程式崩潰.

如果分配的記憶體沒有及時釋放會造成記憶體佔用不斷上升，以至於系統運行一段時間後當機.

對於集合而言, 值引用與地址引用的語義差異不論對於系統架構的設計者或是程式開發人員而言都是比較麻煩的事.  比如我們在將一個對象添加進一個集合之後,  我們再改變這個對象的屬性時集合中的對象需不需要反映這個對象的目前狀態?  在某些情況下我們可能需要它同時更改，但在另外一些情境下我們可能希望這個原對象與集合裡面的這個對象是兩個不同的單位, 集中裡那個只不過是在添加時產生的一個複製體，在此後的時間裡面它們的狀態將可以獨立改變而不互相影響.

如果是地址引用，那麼當這個原始對象失效的時候，那麼集合裡面的引用地址將指向一個無效的記憶體位址， 除非你顯式地去更新這個集合對象，但問題我們有時候很難去維護這種關係.

對於值引用而言, 如果對象裡面還包含有子物件，那麼 這個時候又將怎麼處理呢?

為了製作這樣一個合適的集合即我們的容器，又有一些新的思想被提出來，比如對象引用計數，Handle技術等等處理方式. 為了更一步把演算法和資料結構抽象出來於是又有了STD庫這樣的東西(類似於C#的泛型技術). 當然這裡還需要考慮一些諸如給調用代碼什麼樣的介面, 錯誤處理機制等. 如什麼樣的東西應該隱藏在內部實際，什麼東西應該由客戶代碼去處理.

還有一個重要東西就是動態記憶體位址分配，因為象數組這種東西它的容量是相對固定，如果需要改變它的大小就需要重新分配記憶體，而我們有時候很需要一個容量可以動態變化的這樣一個容器. 這就需要將記憶體這部分冗長工作的複雜性通過某種資料結構隱藏起來.

瞭解了C++的這些內容之後再回過頭來看C#，你會發現用C#是那麼的舒服，因為有很多事情CLR都幫你去完成了，比如記憶體空間的分配，對象何時從記憶體中移除(它會進行自動對象引用計數, 歸零時即有可能被GC回收)等等問題, GC在裡面發揮了重要的作用. 這讓我想起了駭客帝國裡面的情境：對於身處系統中的人，你可能什麼都感覺不到，你甚至感覺不到“系統”的存在，但是當你突破了這層限制你就會看到另一個世界.

然爾通常的看法是C++並不因它的複雜性而被淘汰，“它更象一些精巧的工具”, 你可以用它製造一些精密的結構或用於製造其它工具， 它可以長時間穩定而高速地運行, 而象C#，它讓人更多地考慮功能邏輯的實現，讓程式員從繁雜的記憶體管理工作中解脫出來，從而也避免了很多犯錯誤的機會. 雖然犧牲了一部分效能作為代價，但在很多情況下都是可以接受的，何況在今天這種硬體計算速度高速增長的時代裡.

"複雜性不可避免, 但是應該將這些複雜性向更高的抽象層次隱藏起來", 這當然是大勢所趨，而C#正是因此誕生。正如電腦，就單個組件來講，其實它們自身已經具有相當的複雜性了，想想當年的電腦，動輒幾間房那麼大，現在可以作得這麼小，就在於它將它的內部複雜性很好地隱藏起來，作為使用者來講我們不用關心它的具體實現, 不論是三星的硬碟還是西捷的硬碟，無論是快閃記憶體還是SCSI都可以完成我們的儲存需要. 也正是這樣我們才可以在此之上構建一些更進階的結構.

總而言之，記憶體管理是C/C++程式員的痛苦根源.