第三章.        資源管理

資源是這樣一種東西：一旦你借助它們所做的事情完成了，你必須要將其返回給系統(tǒng)。如果你沒有這樣做，那么不好的事情就會(huì)發(fā)生。在 C++ 程序中，最常用的資源是動(dòng)態(tài)分配的內(nèi)存（如果你分配了內(nèi)存但是卻忘記了釋放它們，你的程序就會(huì)遇到一次內(nèi)存泄漏），但是內(nèi)存只是你所需要管理的眾多資源中的一種。其它常見的資源包括文件主字碼、互斥鎖、以及圖形用戶界面（ GUI ）中的字體和畫筆、數(shù)據(jù)庫聯(lián)接、網(wǎng)絡(luò)套結(jié)字。無論是何種資源，在你借助它所做的工作完成以后都要將其釋放，這一點(diǎn)是很重要的。

試圖手動(dòng)將資源管理得井井有條，在任何情況下都是很困難的事情。但當(dāng)問題轉(zhuǎn)向異常處理、多路返回函數(shù)、以及當(dāng)維護(hù)程序員在未對(duì)其所作的修改有充分理解之前就輕舉妄動(dòng)時(shí)，你就會(huì)清楚地發(fā)現(xiàn)，專門用來解決資源管理問題的方法并不是很充足。

本章以介紹一個(gè)基于對(duì)象的資源管理方法開始，該方法構(gòu)建于 C++ 所支持的構(gòu)造函數(shù)、析構(gòu)函數(shù)、拷貝操作符之上。實(shí)踐顯示，如果嚴(yán)格時(shí)刻堅(jiān)持這一方法，便可以消滅資源管理中幾乎全部的潛在問題。本章稍靠后一些的條目中將專門講解內(nèi)存管理的問題。這些條目是對(duì)前邊較為一般化的條目的補(bǔ)充，因?yàn)楣芾韮?nèi)存的對(duì)象需要搞清楚如何正常工作。

第13條：     要使用對(duì)象來管理資源

在下面的示例中，我們的工作將圍繞一個(gè)模擬投資（或者是股票、證券等等，均可）的庫展開，在這個(gè)庫中，各種各樣的投資類型都繼承自同一個(gè)基類—— Investment ：

我們繼續(xù)上面的示例，供我們使用的庫中，為我們提供具體 Investment 對(duì)象是通過工廠函數(shù)（參見第 7 條）來實(shí)現(xiàn)的：

從上面代碼中的注釋中可以看出，當(dāng) createInvestment 的調(diào)用者完成對(duì)于 createInvestment 函數(shù)返回對(duì)象的操作后，這類調(diào)用者應(yīng)負(fù)責(zé)刪除這一對(duì)象。請(qǐng)看下邊的代碼，我們用 f 函數(shù)來承擔(dān)這一責(zé)任：

這看上去可以正常運(yùn)行，但是 f 可能在一些情況下無法成功的刪除來自 createInvestment 的對(duì)象。在上述代碼的“ ... ”部分可能存在不成熟的 return 語句。如果這樣的 return 語句得到了執(zhí)行，那么程序永遠(yuǎn)就不會(huì)轉(zhuǎn)向 delete 語句執(zhí)行。當(dāng)在循環(huán)語句中使用 createInvestment 和 delete 時(shí)，會(huì)出現(xiàn)類似的情形，同時(shí)這樣的循環(huán)也有可能因遇到 continue 或 goto 語句而提前退出。最后，“ ... ”中的一些語句還有可能拋出異常。如果真的有異常拋出，程序同樣也不會(huì)達(dá)到 delete 。無論 delete 是如何被跳過的，包含 Investment 對(duì)象的內(nèi)存都有可能泄露，同時(shí)這類對(duì)象所控制的資源都有可能得不到釋放。

當(dāng)然，用心編程就有可能防止這類錯(cuò)誤發(fā)生，但是請(qǐng)想象一下代碼會(huì)多么的不固定——你需要不停地修改代碼。在軟件維護(hù)的過程中，為一個(gè)函數(shù)添加 return 或 continue 語句可能會(huì)對(duì)其資源管理策略造成怎樣的影響呢，一些人可能由于不完全理解這一問題就這樣做了。還有更嚴(yán)重的，就是 f 函數(shù)的“ ... ”部分可能調(diào)用了一個(gè)這樣的函數(shù)：它原先從不會(huì)拋出異常，但在其得到“改進(jìn)”之后，它突然又開始能夠拋出異常了。寄希望于 f 函數(shù)總能達(dá)到其中的 delete 語句并不可靠。

為了確保 createInvestment 所返回的資源總能得到釋放，我們需要將這類資源放置在一個(gè)對(duì)象中，這一對(duì)象的析構(gòu)函數(shù)應(yīng)在程序離開 f 之后自動(dòng)釋放資源。實(shí)際上，這是本條目所蘊(yùn)含的思想的一半：那就是將資源放置在對(duì)象中，我們可以寄希望于通過調(diào)用 C++ 的默認(rèn)析構(gòu)函數(shù)，從而確保資及時(shí)源得到釋放。

許多資源是在堆上動(dòng)態(tài)分配的，并且僅僅在單一的程序塊或函數(shù)中使用，同時(shí)這類資源應(yīng)該在程序離開這一程序塊或函數(shù)之前得到釋放。標(biāo)準(zhǔn)庫中的 auto_ptr 就是為這類情況量身定做的。 auto_ptr 是一個(gè)類似于指針的對(duì)象（一個(gè)智能指針），其析構(gòu)函數(shù)可以自動(dòng)地對(duì)用其所指的內(nèi)容執(zhí)行 delete 。以下的代碼描述了如何使用 auto_ptr 來防止 f 潛在的資源泄露。

這一簡(jiǎn)單的示例向我們展示了使用對(duì)象管理資源的兩大關(guān)鍵問題：

l 獲取資源后，立即將資源轉(zhuǎn)交給資源管理對(duì)象。 上邊的示例中 ， createInvestment 返回的資源將初始化一個(gè) auto_ptr ，從而實(shí)現(xiàn)對(duì)這類資源的管理。事實(shí)上，使用對(duì)象來管理資源的理念通常稱為“資源獲取即初始化”（ Resource Acquisition Is Initialization ， 簡(jiǎn)稱 RAII ），這是因?yàn)樵谕粋€(gè)語句中獲取一個(gè)資源并且初始化一個(gè)資源管理對(duì)象是很平常的。某些時(shí)候獲取資源就是為一個(gè)資源管理對(duì)象賦值，而不是初始化。但是無論是哪種途徑，在獲取資源時(shí)，每一個(gè)資源都都會(huì)立即轉(zhuǎn)向一個(gè)資源管理對(duì)象。

l 資源管理對(duì)象使用其析構(gòu)函數(shù)來確保資源得到釋放。 由于析構(gòu)函數(shù)是在對(duì)象銷毀時(shí)自動(dòng)調(diào)用的（比如，當(dāng)對(duì)象將到達(dá)其作用域之外），所以不管程序是如何離開一個(gè)塊的，資源都會(huì)被正確地釋放。如果釋放資源會(huì)帶來異常，那么事情就會(huì)變得錯(cuò)綜復(fù)雜。但是那第 8 條中介紹的內(nèi)容，我們這里不關(guān)心這些。

由于當(dāng)一個(gè) auto_ptr 被銷毀時(shí)，它 自動(dòng)刪除了其所指向的內(nèi)容，所以永遠(yuǎn)不要讓多個(gè) auto_ptr 指向同一個(gè)對(duì)象，這一點(diǎn)很重要。如果你這樣做了，這個(gè)對(duì)象就會(huì)被多次刪除，這樣你的程序就會(huì)陷入未知行為的陷阱。為了防止此類問題發(fā)生， auto_ptr 有一個(gè)不同尋常的特性：如果你復(fù)制它們（通過拷貝構(gòu)造函數(shù)或者拷貝賦值運(yùn)算符），它們就會(huì)被重設(shè)為 null ，然后資源的所有權(quán)將由復(fù)制出的指針獨(dú)占！

在這一古怪的復(fù)制方法中，由于 auto_ptr 必須僅僅指向一個(gè)資源，因此增加了對(duì)于資源管理的潛在需求。這意味著 auto_ptr 并不適合于所有動(dòng)態(tài)分配的資源。比如說， STL 容器要求其內(nèi)容的表現(xiàn)出“正常”的拷貝行為，所以 auto_ptr 的容器是不允許使用的。

引用計(jì)數(shù)智能指針（ reference-counting smart pointer ， 簡(jiǎn)稱 RCSP ）是 auto_ptr 的一個(gè)替代品。一個(gè) RCSP 是一個(gè)這樣的智能指針：它可以跟蹤有多少的對(duì)象指向了一個(gè)特定的 資源，同時(shí)當(dāng)沒有指針在指向這一資源時(shí)，智能指針會(huì)自動(dòng)刪除這一資源。可以看出， RCSP 的行為與垃圾回收機(jī)很相似。然而， RCSP 與垃圾回收機(jī)也不是完全一樣的，它不能夠打斷循環(huán)引用（比如說，兩個(gè)沒有其它使用者的對(duì)象 互相指向?qū)Ψ剑?/span>

TR1 的 TR1::shared_ptr 就是一個(gè) RCSP ， 于是你可以按下面的方式來編寫 f ：

上面的代碼與使用 auto_ptr 是幾乎完全相同，但是復(fù)制 shared_ptr 的行為更加自然：

由于復(fù)制 TR1::shared_ptr 的工作可以“如期進(jìn) 行 ” ，所以在 auto_ptr 會(huì)出現(xiàn)非正統(tǒng)的復(fù)制行為的地方，比如 STL 容 器以及其它一些上下文中，這類指針能夠安全地應(yīng)用。

但是，請(qǐng)不要迷失方向。本條目并不是專門講解 auto_ptr 和 TR1::shared_ptr 的，也不是講解智能指針的。本條目的核心內(nèi)容是使用對(duì)象管理資源的重要性。 auto_ptr 和 TR1::shared_ptr 僅僅是這類對(duì)象的示例。（關(guān)于 TR1::shared_ptr 的更多信息，請(qǐng)參見第 14 、 18 和 54 條。）

auto_ptr 和 TR1::shared_ptr 在析構(gòu)函數(shù)中都包含 delete 語句，而不是 delete[] 。（第 16 條中描述了二者的區(qū)別。）這就意味著對(duì)于動(dòng)態(tài)分配的數(shù)組使用 auto_ptr 和 TR1::shared_ptr 不是一個(gè)好主意。但是遺憾的是，這樣的代碼會(huì)通過編譯：

你可能會(huì)很吃驚，因?yàn)樵?/span> C++ 中沒有類似于 auto_ptr 和 TR1::shared_ptr 的方案來解決動(dòng)態(tài)分配數(shù)組的問題，甚至 TR1 中也沒有。這是因?yàn)?/span> vector 和 string 通常都可以代替動(dòng)態(tài)分配的數(shù)組。如果你仍然希望存在類似于 auto_ptr 和 TR1::shared_ptr 的數(shù)組類，請(qǐng)參見 Boost 的相關(guān)內(nèi)容（見 第 55 條 ）。那兒會(huì)滿足你需求： Boost 提供了 boost::scoped_array 和 boost::shared_array 來處理相關(guān)問題。

本條目中建議你始終使用對(duì)象來管理資源。如果你手動(dòng)釋放資源（比如使用 delete 而不是使用資源管理類），你就在做一些錯(cuò)事。諸如 auto_ptr 和 TR1::shared_ptr 等封裝好的資源管理類通常可以讓遵循本條目的建議變成一件很容易的事情，但是某些情況下，你的問題無法使用這些預(yù)制的類來解決，此時(shí)你便需要?jiǎng)?chuàng)建自己的資源管理類。但這并沒有想象中那么難，但是確實(shí)需要你考慮一些細(xì)節(jié)問題。這些細(xì)節(jié)問題就是第 14 和 15 條的主題。

最后說一下，我必須指出 createInvestment 的裸指針返回類型存在著潛在的內(nèi)存泄露問題，因?yàn)檎{(diào)用者十分容易忘記在返回時(shí)調(diào)用 delete 。（甚至在它們使用 auto_ptr 或 TR1::shared_ptr 來運(yùn)行 delete 時(shí)，他們?nèi)匀恍枰谝粋€(gè)智能指針對(duì)象中保存 createInvestment 的返回值。）解決這一問題需要改變 createInvestment 的對(duì)象，這是第 18 條的主題。

牢記在心

l 為了避免資源泄露，可以使用 RAII 對(duì)象，使用構(gòu)造函數(shù)獲取資源，析構(gòu)函數(shù)釋放資源。

l auto_ptr 或 TR1::shared_ptr 是 兩個(gè)常用并且實(shí)用的 RAII 類。通常情況 下 TR1::shared_ptr 是更好的選擇，因?yàn)樗膹?fù)制行為更加直觀。復(fù)制一個(gè) auto_ptr 將會(huì)使其重設(shè)為 null 。