對C++資源管理內容分析研究
下面進行對C++資源管理的問題進行講解，那么首先要對C++語言的概念進行了解，所謂C++語言：它是一種使用非常廣泛的計算機編程語言，C++已經成為當今主流程序設計語言中最復雜的一員。
首先簡要的介紹一下 RAII 。這個思想的基本手法是對于一種想要使用的資源，為其書寫一個 guard 類，在該類的構造函數里進行資源的請求，在析構函數里進行資源的釋放。例如假設我們想管理一個互斥鎖，可能的方式是：
- struct lock_guard
- {
- lock_guard() { lock ();}
- ~ lock_guard() {unlock();}
- } ;
此后，對這個對象使用什么內存管理方式，也就等價于對這個互斥鎖使用什么內存管理方式。借助于 RAII ，以后我們可以只討論內存資源的管理方式，其它資源的管理方式可以使用 RAII 來同樣的實現。
現在我們已經很自然的獲得了資源管理的 3 種方式：基于堆的動態方式、基于棧的自動方式和全局。值得一提的是，這 3 種方式中比較不容易出錯的后兩種實際上可以解決大部分的資源管理需求。
因為絕大部分資源，都屬于獲取 - 使用 - 釋放型的，例如很多同步對象，文件鎖， WinGDI 里的許多 GDI 對象。我們缺乏管理的，只有那些一次獲得，多個環境擁有，并且只能有一次釋放的少數資源。
回到內存模型來看，有一點讓我們無法將內存與其它資源等同（反過來，把其它資源和內存等同卻是可以的），那就是循環引用。
A 內存可以持有指向 B 內存的引用， B 內存也可以反過來持有 A 內存的引用。循環引用導致內存管理不可以用“是否有指向該內存的引用”來區分一塊內存是否可以回收。從而喪失了一個***的管理手段。但是在沒有循環引用的場合下，我們還是有非常簡潔高效的管理方法的。那就是引用計數。
引用計數是在沒有循環引用場合下進行內存管理的***手段，它具有輕量、高效、即時、可控的優點。而且在C++資源管理里，引用計數已經非常成熟，只需要使用 boost.shared_ptr 或者其它非官方的引用計數指針庫就可以了，而且據悉 C++資源管理很可能把 boost.shared_ptr 納入標準庫。
引用計數的原則是，如果一個對象沒有別的指針或引用來指向它，那么這個對象就是可以釋放的。引用計數通常可以處理哪些場合的資源管理問題呢？首先，對于單方向的資源管理，也就是多個 A 的實體擁有 1 個 B ，然而 B 并不會反過來依賴于 A （例如多個對象共享一個日志），引用計數是非常合適的。
其次，對于擁有反作用的場合，也就是 1 個或多個 A 的實體擁有 1 個或多個 B ，而 B 也擁有這些 A 的實體的引用，但是 B 的生存期仍然決定于 A 的生存期（例如父窗口擁有若干子窗口，子窗口也具有 parent 指針指向父窗口。
但是子窗口的生存期決定于父窗口的生存期），這個時候 A 可以對 B 使用引用計數指針，而 B 可以對 A 使用原生的普通指針，同樣的可以很好的解決問題。 現在所剩下的，就只有生存期的循環依賴了。如果 AB 互相持有對方的引用，而且 AB 互相的存在都依賴于對方，這樣引用計數就無法解決了。
但是如果仔細想一下就會發現，這種情況在C++資源管理里幾乎不可能存在。生存期循環依賴只有 2 種后果，要么 A 和 B 的析構函數里互相析構（當然就掛了），要么互相都不析構（當然就泄露了）。#t#
而這兩種都是在正常編程中不會出現的情況。所以如果即使僅僅使用引用計數，我們也可以解決幾乎所有的資源管理問題。 現在回過頭來看 Java/C# 這樣的內置 gc 的語言。這樣的語言由于使用了 gc ，就不可避免的放棄了析構函數。為什么 gc 會和析構函數產生沖突呢？
一個 gc 一般會希望在進行垃圾回收的時候，整個過程是一個原子的，但析構函數會破壞這一點，在釋放內存的時候如果還要執行代碼，那么難免會對整個 gc 環境產生破壞性的影響。
由于沒有析構函數，這些語言就不可能做到 RAII ，也就是說，它們的C++資源管理所能夠管理的，也就僅僅只有內存而已了。對于其他資源， Java 等就必須手動釋放。雖然 C# 提供了 with 關鍵字來緩解這一問題，但仍然無法徹底的解決。
