內(nèi)存管理是C++最令人切齒痛恨的問題，也是C++最有爭(zhēng)議的問題，C++高手從中獲得了更好的性能，更大的自由，C++菜鳥的收獲則是一遍一遍的檢查代碼和對(duì) C++的痛恨，但內(nèi)存管理在C++中無(wú)處不在，內(nèi)存泄漏幾乎在每個(gè)C++程序中都會(huì)發(fā)生，因此要想成為C++高手，內(nèi)存管理一關(guān)是必須要過的，除非放棄 C++，轉(zhuǎn)到Java或者.NET，他們的內(nèi)存管理基本是自動(dòng)的，當(dāng)然你也放棄了自由和對(duì)內(nèi)存的支配權(quán)，還放棄了C++超絕的性能。本期專題將從內(nèi)存管 理、內(nèi)存泄漏、內(nèi)存回收這三個(gè)方面來(lái)探討C++內(nèi)存管理問題。
1 內(nèi)存管理
偉大的Bill Gates 曾經(jīng)失言：
640K ought to be enough for everybody — Bill Gates 1981
程序員們經(jīng)常編寫內(nèi)存管理程序，往往提心吊膽。如果不想觸雷，唯一的解決辦法就是發(fā)現(xiàn)所有潛伏的地雷并且排除它們，躲是躲不了的。本文的內(nèi)容比一般教科書的要深入得多，讀者需細(xì)心閱讀，做到真正地通曉內(nèi)存管理。
1.1 C++內(nèi)存管理詳解
1.1.1 內(nèi)存分配方式
1.1.1.1 分配方式簡(jiǎn)介
在C++中，內(nèi)存分成5個(gè)區(qū)，他們分別是堆、棧、自由存儲(chǔ)區(qū)、全局/靜態(tài)存儲(chǔ)區(qū)和常量存儲(chǔ)區(qū)。
棧，在執(zhí)行函數(shù)時(shí)，函數(shù)內(nèi)局部變量的存儲(chǔ)單元都可以在棧上創(chuàng)建，函數(shù)執(zhí)行結(jié)束時(shí)這些存儲(chǔ)單元自動(dòng)被釋放。棧內(nèi)存分配運(yùn)算內(nèi)置于處理器的指令集中，效率很高，但是分配的內(nèi)存容量有限。
堆，就是那些由new分配的內(nèi)存塊，他們的釋放編譯器不去管，由我們的應(yīng)用程序去控制，一般一個(gè)new就要對(duì)應(yīng)一個(gè)delete。如果程序員沒有釋放掉，那么在程序結(jié)束后，操作系統(tǒng)會(huì)自動(dòng)回收。
自由存儲(chǔ)區(qū)，就是那些由malloc等分配的內(nèi)存塊，他和堆是十分相似的，不過它是用free來(lái)結(jié)束自己的生命的。
全局/靜態(tài)存儲(chǔ)區(qū)，全局變量和靜態(tài)變量被分配到同一塊內(nèi)存中，在以前的C語(yǔ)言中，全局變量又分為初始化的和未初始化的，在C++里面沒有這個(gè)區(qū)分了，他們共同占用同一塊內(nèi)存區(qū)。
常量存儲(chǔ)區(qū)，這是一塊比較特殊的存儲(chǔ)區(qū)，他們里面存放的是常量，不允許修改。
1.1.1.2 明確區(qū)分堆與棧
在bbs上，堆與棧的區(qū)分問題，似乎是一個(gè)永恒的話題，由此可見，初學(xué)者對(duì)此往往是混淆不清的，所以我決定拿他第一個(gè)開刀。
首先，我們舉一個(gè)例子：
| void f() { int* p=new int[5]; } |
這條短短的一句話就包含了堆與棧，看到new，我們首先就應(yīng)該想到，我們分配了一塊堆內(nèi)存，那么指針p呢？他分配的是一塊棧內(nèi)存，所以這句話的意思就是：在棧內(nèi)存中存放了一個(gè)指向一塊堆內(nèi)存的指針p。在程序會(huì)先確定在堆中分配內(nèi)存的大小，然后調(diào)用operator new分配內(nèi)存，然后返回這塊內(nèi)存的首地址，放入棧中，他在VC6下的匯編代碼如下：
| 00401028 push 14h 0040102A call operator new (00401060) 0040102F add esp,4 00401032 mov dword ptr [ebp-8],eax 00401035 mov eax,dword ptr [ebp-8] 00401038 mov dword ptr [ebp-4],eax |
這里，我們?yōu)榱撕?jiǎn)單并沒有釋放內(nèi)存，那么該怎么去釋放呢？是delete p么？澳，錯(cuò)了，應(yīng)該是delete []p，這是為了告訴編譯器：我刪除的是一個(gè)數(shù)組，VC6就會(huì)根據(jù)相應(yīng)的Cookie信息去進(jìn)行釋放內(nèi)存的工作。
1.1.1.3 堆和棧究竟有什么區(qū)別？
好了，我們回到我們的主題：堆和棧究竟有什么區(qū)別？
主要的區(qū)別由以下幾點(diǎn)：
1、管理方式不同；
2、空間大小不同；
3、能否產(chǎn)生碎片不同；
4、生長(zhǎng)方向不同；
5、分配方式不同；
6、分配效率不同；
管理方式：對(duì)于棧來(lái)講，是由編譯器自動(dòng)管理，無(wú)需我們手工控制；對(duì)于堆來(lái)說，釋放工作由程序員控制，容易產(chǎn)生memory leak。
空間大�。阂话銇�(lái)講在32位系統(tǒng)下，堆內(nèi)存可以達(dá)到4G的空間，從這個(gè)角度來(lái)看堆內(nèi)存幾乎是沒有什么限制的。但是對(duì)于棧來(lái)講，一般都是有一定的空間大小的，例如，在VC6下面，默認(rèn)的�？臻g大小是1M（好像是，記不清楚了）。當(dāng)然，我們可以修改：
打開工程，依次操作菜單如下：Project->Setting->Link，在Category 中選中Output，然后在Reserve中設(shè)定堆棧的最大值和commit。
注意：reserve最小值為4Byte；commit是保留在虛擬內(nèi)存的頁(yè)文件里面，它設(shè)置的較大會(huì)使棧開辟較大的值，可能增加內(nèi)存的開銷和啟動(dòng)時(shí)間。
碎片問題：對(duì)于堆來(lái)講，頻繁的new/delete勢(shì) 必會(huì)造成內(nèi)存空間的不連續(xù)，從而造成大量的碎片，使程序效率降低。對(duì)于棧來(lái)講，則不會(huì)存在這個(gè)問題，因?yàn)闂Ｊ窍冗M(jìn)后出的隊(duì)列，他們是如此的一一對(duì)應(yīng)，以至 于永遠(yuǎn)都不可能有一個(gè)內(nèi)存塊從棧中間彈出，在他彈出之前，在他上面的后進(jìn)的棧內(nèi)容已經(jīng)被彈出，詳細(xì)的可以參考數(shù)據(jù)結(jié)構(gòu)，這里我們就不再一一討論了。
生長(zhǎng)方向：對(duì)于堆來(lái)講，生長(zhǎng)方向是向上的，也就是向著內(nèi)存地址增加的方向；對(duì)于棧來(lái)講，它的生長(zhǎng)方向是向下的，是向著內(nèi)存地址減小的方向增長(zhǎng)。
分配方式：堆都是動(dòng)態(tài)分配的，沒有靜態(tài)分配的堆。棧有2種分配方式：靜態(tài)分配和動(dòng)態(tài)分配。靜態(tài)分配是編譯器完成的，比如局部變量的分配。動(dòng)態(tài)分配由alloca函數(shù)進(jìn)行分配，但是棧的動(dòng)態(tài)分配和堆是不同的，他的動(dòng)態(tài)分配是由編譯器進(jìn)行釋放，無(wú)需我們手工實(shí)現(xiàn)。
分配效率：棧是機(jī)器系統(tǒng)提供的數(shù)據(jù)結(jié)構(gòu)，計(jì)算機(jī)會(huì)在底層對(duì)棧提供支持：分配專門的寄存器存放棧的地址，壓棧出棧都有專門的指令執(zhí)行，這就決定了棧的效率比較高。堆則是C/C++函數(shù)庫(kù)提供的，它的機(jī)制是很復(fù)雜的，例如為了分配一塊內(nèi)存，庫(kù)函數(shù)會(huì)按照一定的算法（具體的算法可以參考數(shù)據(jù)結(jié)構(gòu)/操作系統(tǒng)）在堆內(nèi)存中搜索可用的足夠大小的空間，如果沒有足夠大小的空間（可能是由于內(nèi)存碎片太多），就有可能調(diào)用系統(tǒng)功能去增加程序數(shù)據(jù)段的內(nèi)存空間，這樣就有機(jī)會(huì)分到足夠大小的內(nèi)存，然后進(jìn)行返回。顯然，堆的效率比棧要低得多。
從這里我們可以看到，堆和棧相比，由于大量new/delete的使用，容易造成大量的內(nèi)存碎片；由于沒有專門的系統(tǒng)支持，效率很低；由于可能引發(fā)用戶態(tài)和核心態(tài)的切換，內(nèi)存的申請(qǐng)，代價(jià)變得更加昂貴。所以棧在程序中是應(yīng)用最廣泛的，就算是函數(shù)的調(diào)用也利用棧去完成，函數(shù)調(diào)用過程中的參數(shù)，返回地址，EBP和局部變量都采用棧的方式存放。所以，我們推薦大家盡量用棧，而不是用堆。
雖然棧有如此眾多的好處，但是由于和堆相比不是那么靈活，有時(shí)候分配大量的內(nèi)存空間，還是用堆好一些。
無(wú)論是堆還是棧，都要防止越界現(xiàn)象的發(fā)生（除非你是故意使其越界），因?yàn)樵浇绲慕Y(jié)果要么是程序崩潰，要么是摧毀程序的堆、棧結(jié)構(gòu)，產(chǎn)生以想不到的結(jié)果,就算是在你的程序運(yùn)行過程中，沒有發(fā)生上面的問題，你還是要小心，說不定什么時(shí)候就崩掉，那時(shí)候debug可是相當(dāng)困難的：）
1.1.2 控制C++的內(nèi)存分配
在嵌入式系統(tǒng)中使用C++的一個(gè)常見問題是內(nèi)存分配，即對(duì)new 和 delete 操作符的失控。
具有諷刺意味的是，問題的根源卻是C++對(duì)內(nèi)存的管理非常的容易而且安全。具體地說，當(dāng)一個(gè)對(duì)象被消除時(shí)，它的析構(gòu)函數(shù)能夠安全的釋放所分配的內(nèi)存。
這當(dāng)然是個(gè)好事情，但是這種使用的簡(jiǎn)單性使得程序員們過度使用new 和 delete，而不注意在嵌入式C++環(huán)境中的因果關(guān)系。并且，在嵌入式系統(tǒng)中，由于內(nèi)存的限制，頻繁的動(dòng)態(tài)分配不定大小的內(nèi)存會(huì)引起很大的問題以及堆破碎的風(fēng)險(xiǎn)。
作為忠告，保守的使用內(nèi)存分配是嵌入式環(huán)境中的第一原則。
但當(dāng)你必須要使用new 和delete時(shí)，你不得不控制C++中的內(nèi)存分配。你需要用一個(gè)全局的new 和delete來(lái)代替系統(tǒng)的內(nèi)存分配符，并且一個(gè)類一個(gè)類的重載new 和delete。
一個(gè)防止堆破碎的通用方法是從不同固定大小的內(nèi)存持中分配不同類型的對(duì)象。對(duì)每個(gè)類重載new 和delete就提供了這樣的控制。
1.1.2.1 重載全局的new和delete操作符
可以很容易地重載new 和 delete 操作符，如下所示:
| void * operator new(size_t size) { void *p = malloc(size); return (p); } void operator delete(void *p); { free(p); } |
這段代碼可以代替默認(rèn)的操作符來(lái)滿足內(nèi)存分配的請(qǐng)求。出于解釋C++的目的，我們也可以直接調(diào)用malloc() 和free()。
也可以對(duì)單個(gè)類的new 和 delete 操作符重載。這是你能靈活的控制對(duì)象的內(nèi)存分配。
| class TestClass { public: void * operator new(size_t size); void operator delete(void *p); // .. other members here ... }; void *TestClass::operator new(size_t size) { void *p = malloc(size); // Replace this with alternative allocator return (p); } void TestClass::operator delete(void *p) { free(p); // Replace this with alternative de-allocator } |
所有TestClass 對(duì)象的內(nèi)存分配都采用這段代碼。更進(jìn)一步，任何從TestClass 繼承的類也都采用這一方式，除非它自己也重載了new 和 delete 操作符。通過重載new 和 delete 操作符的方法，你可以自由地采用不同的分配策略，從不同的內(nèi)存池中分配不同的類對(duì)象。
1.1.2.2 為單個(gè)的類重載 new[ ]和delete[ ]
必須小心對(duì)象數(shù)組的分配。你可能希望調(diào)用到被你重載過的new 和 delete 操作符，但并不如此。內(nèi)存的請(qǐng)求被定向到全局的new[ ]和delete[ ] 操作符，而這些內(nèi)存來(lái)自于系統(tǒng)堆。
C++將對(duì)象數(shù)組的內(nèi)存分配作為一個(gè)單獨(dú)的操作，而不同于單個(gè)對(duì)象的內(nèi)存分配。為了改變這種方式，你同樣需要重載new[ ] 和 delete[ ]操作符。
| class TestClass { public: void * operator new[ ](size_t size); void operator delete[ ](void *p); // .. other members here .. }; void *TestClass::operator new[ ](size_t size) { void *p = malloc(size); return (p); } void TestClass::operator delete[ ](void *p) { free(p); } int main(void) { TestClass *p = new TestClass[10]; // ... etc ... delete[ ] p; } |
但是注意：對(duì)于多數(shù)C++的實(shí)現(xiàn)，new[]操作符中的個(gè)數(shù)參數(shù)是數(shù)組的大小加上額外的存儲(chǔ)對(duì)象數(shù)目的一些字節(jié)。在你的內(nèi)存分配機(jī)制重要考慮的這一點(diǎn)。你應(yīng)該盡量避免分配對(duì)象數(shù)組，從而使你的內(nèi)存分配策略簡(jiǎn)單。
1.1.3 常見的內(nèi)存錯(cuò)誤及其對(duì)策
發(fā)生內(nèi)存錯(cuò)誤是件非常麻煩的事情。編譯器不能自動(dòng)發(fā)現(xiàn)這些錯(cuò)誤，通常是在程序運(yùn)行時(shí)才能捕捉到。而這些錯(cuò)誤大多沒有明顯的癥狀，時(shí)隱時(shí)現(xiàn)，增加了改錯(cuò)的難度。有時(shí)用戶怒氣沖沖地把你找來(lái)，程序卻沒有發(fā)生任何問題，你一走，錯(cuò)誤又發(fā)作了。 常見的內(nèi)存錯(cuò)誤及其對(duì)策如下：
* 內(nèi)存分配未成功，卻使用了它。
編程新手常犯這種錯(cuò)誤，因?yàn)樗麄儧]有意識(shí)到內(nèi)存分配會(huì)不成功。常用解決辦法是，在使用內(nèi)存之前檢查指針是否為NULL。如果指針p是函數(shù)的參數(shù)，那么在函數(shù)的入口處用assert(p!=NULL)進(jìn)行
檢查。如果是用malloc或new來(lái)申請(qǐng)內(nèi)存，應(yīng)該用if(p==NULL) 或if(p!=NULL)進(jìn)行防錯(cuò)處理。
* 內(nèi)存分配雖然成功，但是尚未初始化就引用它。
犯這種錯(cuò)誤主要有兩個(gè)起因：一是沒有初始化的觀念；二是誤以為內(nèi)存的缺省初值全為零，導(dǎo)致引用初值錯(cuò)誤（例如數(shù)組）。 內(nèi)存的缺省初值究竟是什么并沒有統(tǒng)一的標(biāo)準(zhǔn)，盡管有些時(shí)候?yàn)榱阒�，我們寧可信其無(wú)不可信其有。所以無(wú)論用何種方式創(chuàng)建數(shù)組，都別忘了賦初值，即便是賦零值也不可省略，不要嫌麻煩。
* 內(nèi)存分配成功并且已經(jīng)初始化，但操作越過了內(nèi)存的邊界。
例如在使用數(shù)組時(shí)經(jīng)常發(fā)生下標(biāo)“多1”或者“少1”的操作。特別是在for循環(huán)語(yǔ)句中，循環(huán)次數(shù)很容易搞錯(cuò)，導(dǎo)致數(shù)組操作越界。
* 忘記了釋放內(nèi)存，造成內(nèi)存泄露。
含有這種錯(cuò)誤的函數(shù)每被調(diào)用一次就丟失一塊內(nèi)存。剛開始時(shí)系統(tǒng)的內(nèi)存充足，你看不到錯(cuò)誤。終有一次程序突然死掉，系統(tǒng)出現(xiàn)提示：內(nèi)存耗盡。
動(dòng)態(tài)內(nèi)存的申請(qǐng)與釋放必須配對(duì)，程序中malloc與free的使用次數(shù)一定要相同，否則肯定有錯(cuò)誤（new/delete同理）。
* 釋放了內(nèi)存卻繼續(xù)使用它。
有三種情況：
（1）程序中的對(duì)象調(diào)用關(guān)系過于復(fù)雜，實(shí)在難以搞清楚某個(gè)對(duì)象究竟是否已經(jīng)釋放了內(nèi)存，此時(shí)應(yīng)該重新設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)，從根本上解決對(duì)象管理的混亂局面。
（2）函數(shù)的return語(yǔ)句寫錯(cuò)了，注意不要返回指向“棧內(nèi)存”的“指針”或者“引用”，因?yàn)樵搩?nèi)存在函數(shù)體結(jié)束時(shí)被自動(dòng)銷毀。
�。�3）使用free或delete釋放了內(nèi)存后，沒有將指針設(shè)置為NULL。導(dǎo)致產(chǎn)生“野指針”。
【規(guī)則1】用malloc或new申請(qǐng)內(nèi)存之后，應(yīng)該立即檢查指針值是否為NULL。防止使用指針值為NULL的內(nèi)存。
【規(guī)則2】不要忘記為數(shù)組和動(dòng)態(tài)內(nèi)存賦初值。防止將未被初始化的內(nèi)存作為右值使用。
【規(guī)則3】避免數(shù)組或指針的下標(biāo)越界，特別要當(dāng)心發(fā)生“多1”或者“少1”操作。
【規(guī)則4】動(dòng)態(tài)內(nèi)存的申請(qǐng)與釋放必須配對(duì)，防止內(nèi)存泄漏。
【規(guī)則5】用free或delete釋放了內(nèi)存之后，立即將指針設(shè)置為NULL，防止產(chǎn)生“野指針”。
1.1.4 指針與數(shù)組的對(duì)比
C++/C程序中，指針和數(shù)組在不少地方可以相互替換著用，讓人產(chǎn)生一種錯(cuò)覺，以為兩者是等價(jià)的。
數(shù)組要么在靜態(tài)存儲(chǔ)區(qū)被創(chuàng)建（如全局?jǐn)?shù)組），要么在棧上被創(chuàng)建。數(shù)組名對(duì)應(yīng)著（而不是指向）一塊內(nèi)存，其地址與容量在生命期內(nèi)保持不變，只有數(shù)組的內(nèi)容可以改變。
指針可以隨時(shí)指向任意類型的內(nèi)存塊，它的特征是“可變”，所以我們常用指針來(lái)操作動(dòng)態(tài)內(nèi)存。指針遠(yuǎn)比數(shù)組靈活，但也更危險(xiǎn)。
下面以字符串為例比較指針與數(shù)組的特性。
1.1.4.1 修改內(nèi)容
下面示例中，字符數(shù)組a的容量是6個(gè)字符，其內(nèi)容為hello。a的內(nèi)容可以改變，如a[0]= ‘X’。指針p指向常量字符串“world”（位于靜態(tài)存儲(chǔ)區(qū)，內(nèi)容為world），常量字符串的內(nèi)容是不可以被修改的。從語(yǔ)法上看，編譯器并不覺得語(yǔ)句p[0]= ‘X’有什么不妥，但是該語(yǔ)句企圖修改常量字符串的內(nèi)容而導(dǎo)致運(yùn)行錯(cuò)誤。
| char a[] = “hello”; a[0] = ‘X’; cout << a << endl; char *p = “world”; // 注意p指向常量字符串 p[0] = ‘X’; // 編譯器不能發(fā)現(xiàn)該錯(cuò)誤 cout << p << endl; |
1.1.4.2 內(nèi)容復(fù)制與比較
不能對(duì)數(shù)組名進(jìn)行直接復(fù)制與比較。若想把數(shù)組a的內(nèi)容復(fù)制給數(shù)組b，不能用語(yǔ)句 b = a ，否則將產(chǎn)生編譯錯(cuò)誤。應(yīng)該用標(biāo)準(zhǔn)庫(kù)函數(shù)strcpy進(jìn)行復(fù)制。同理，比較b和a的內(nèi)容是否相同，不能用if(b==a) 來(lái)判斷，應(yīng)該用標(biāo)準(zhǔn)庫(kù)函數(shù)strcmp進(jìn)行比較。
語(yǔ)句p = a 并不能把a(bǔ)的內(nèi)容復(fù)制指針p，而是把a(bǔ)的地址賦給了p。要想復(fù)制a的內(nèi)容，可以先用庫(kù)函數(shù)malloc為p申請(qǐng)一塊容量為strlen(a)+1個(gè)字符的內(nèi)存，再用strcpy進(jìn)行字符串復(fù)制。同理，語(yǔ)句if(p==a) 比較的不是內(nèi)容而是地址，應(yīng)該用庫(kù)函數(shù)strcmp來(lái)比較。
| // 數(shù)組… char a[] = "hello"; char b[10]; strcpy(b, a); // 不能用 b = a; if(strcmp(b, a) == 0) // 不能用 if (b == a) … // 指針… int len = strlen(a); char *p = (char *)malloc(sizeof(char)*(len+1)); strcpy(p,a); // 不要用 p = a; if(strcmp(p, a) == 0) // 不要用 if (p == a) … |
1.1.4.3 計(jì)算內(nèi)存容量
用運(yùn)算符sizeof可以計(jì)算出數(shù)組的容量（字節(jié)數(shù)）。如下示例中，sizeof(a)的值是12（注意別忘了’’）。指針p指向a，但是sizeof(p)的值卻是4。這是因?yàn)閟izeof(p)得到的是一個(gè)指針變量的字節(jié)數(shù)，相當(dāng)于sizeof(char*)，而不是p所指的內(nèi)存容量。C++/C語(yǔ)言沒有辦法知道指針?biāo)傅膬?nèi)存容量，除非在申請(qǐng)內(nèi)存時(shí)記住它。
| char a[] = "hello world"; char *p = a; cout<< sizeof(a) << endl; // 12字節(jié) cout<< sizeof(p) << endl; // 4字節(jié) |
注意當(dāng)數(shù)組作為函數(shù)的參數(shù)進(jìn)行傳遞時(shí)，該數(shù)組自動(dòng)退化為同類型的指針。如下示例中，不論數(shù)組a的容量是多少，sizeof(a)始終等于sizeof(char *)。
| void Func(char a[100]) { cout<< sizeof(a) << endl; // 4字節(jié)而不是100字節(jié) } |
1.1.5 指針參數(shù)是如何傳遞內(nèi)存的？
如果函數(shù)的參數(shù)是一個(gè)指針，不要指望用該指針去申請(qǐng)動(dòng)態(tài)內(nèi)存。如下示例中，Test函數(shù)的語(yǔ)句GetMemory(str, 200)并沒有使str獲得期望的內(nèi)存，str依舊是NULL，為什么？
| void GetMemory(char *p, int num) { p = (char *)malloc(sizeof(char) * num); } void Test(void) { char *str = NULL; GetMemory(str, 100); // str 仍然為 NULL strcpy(str, "hello"); // 運(yùn)行錯(cuò)誤 } |
毛病出在函數(shù)GetMemory中。編譯器總是要為函數(shù)的每個(gè)參數(shù)制作臨時(shí)副本，指針參數(shù)p的副本是 _p，編譯器使 _p = p。如果函數(shù)體內(nèi)的程序修改了_p的內(nèi)容，就導(dǎo)致參數(shù)p的內(nèi)容作相應(yīng)的修改。這就是指針可以用作輸出參數(shù)的原因。在本例中，_p申請(qǐng)了新的內(nèi)存，只是把_p所指的內(nèi)存地址改變了，但是p絲毫未變。所以函數(shù)GetMemory并不能輸出任何東西。事實(shí)上，每執(zhí)行一次GetMemory就會(huì)泄露一塊內(nèi)存，因?yàn)闆]有用free釋放內(nèi)存。
如果非得要用指針參數(shù)去申請(qǐng)內(nèi)存，那么應(yīng)該改用“指向指針的指針”，見示例：
| void GetMemory2(char **p, int num) { *p = (char *)malloc(sizeof(char) * num); } void Test2(void) { char *str = NULL; GetMemory2(&str, 100); // 注意參數(shù)是 &str，而不是str strcpy(str, "hello"); cout<< str << endl; free(str); } |
由于“指向指針的指針”這個(gè)概念不容易理解，我們可以用函數(shù)返回值來(lái)傳遞動(dòng)態(tài)內(nèi)存。這種方法更加簡(jiǎn)單，見示例：
| char *GetMemory3(int num) { char *p = (char *)malloc(sizeof(char) * num); return p; } void Test3(void) { char *str = NULL; str = GetMemory3(100); strcpy(str, "hello"); cout<< str << endl; free(str); } |
用函數(shù)返回值來(lái)傳遞動(dòng)態(tài)內(nèi)存這種方法雖然好用，但是常常有人把return語(yǔ)句用錯(cuò)了。這里強(qiáng)調(diào)不要用return語(yǔ)句返回指向“棧內(nèi)存”的指針，因?yàn)樵搩?nèi)存在函數(shù)結(jié)束時(shí)自動(dòng)消亡，見示例：
| char *GetString(void) { char p[] = "hello world"; return p; // 編譯器將提出警告 } void Test4(void) { char *str = NULL; str = GetString(); // str 的內(nèi)容是垃圾 cout<< str << endl; } |
用調(diào)試器逐步跟蹤Test4，發(fā)現(xiàn)執(zhí)行str = GetString語(yǔ)句后str不再是NULL指針，但是str的內(nèi)容不是“hello world”而是垃圾。
如果把上述示例改寫成如下示例，會(huì)怎么樣？
| char *GetString2(void) { char *p = "hello world"; return p; } void Test5(void) { char *str = NULL; str = GetString2(); cout<< str << endl; } |
函數(shù)Test5運(yùn)行雖然不會(huì)出錯(cuò)，但是函數(shù)GetString2的設(shè)計(jì)概念卻是錯(cuò)誤的。因?yàn)镚etString2內(nèi)的“hello world”是常量字符串，位于靜態(tài)存儲(chǔ)區(qū)，它在程序生命期內(nèi)恒定不變。無(wú)論什么時(shí)候調(diào)用GetString2，它返回的始終是同一個(gè)“只讀”的內(nèi)存塊。
1.1.6 杜絕“野指針”
“野指針”不是NULL指針，是指向“垃圾”內(nèi)存的指針。人們一般不會(huì)錯(cuò)用NULL指針，因?yàn)橛胕f語(yǔ)句很容易判斷。但是“野指針”是很危險(xiǎn)的，if語(yǔ)句對(duì)它不起作用。 “野指針”的成因主要有兩種：
（1）指針變量沒有被初始化。任何指針變量剛被創(chuàng)建時(shí)不會(huì)自動(dòng)成為NULL指針，它的缺省值是隨機(jī)的，它會(huì)亂指一氣。所以，指針變量在創(chuàng)建的同時(shí)應(yīng)當(dāng)被初始化，要么將指針設(shè)置為NULL，要么讓它指向合法的內(nèi)存。例如
| char *p = NULL; char *str = (char *) malloc(100); |
（2）指針p被free或者delete之后，沒有置為NULL，讓人誤以為p是個(gè)合法的指針。
（3）指針操作超越了變量的作用域范圍。這種情況讓人防不勝防，示例程序如下：
| class A { public: void Func(void){ cout << “Func of class A” << endl; } }; void Test(void) { A *p; { A a; p = &a; // 注意 a 的生命期 } p->Func(); // p是“野指針” } |
函數(shù)Test在執(zhí)行語(yǔ)句p->Func()時(shí)，對(duì)象a已經(jīng)消失，而p是指向a的，所以p就成了“野指針”。但奇怪的是我運(yùn)行這個(gè)程序時(shí)居然沒有出錯(cuò)，這可能與編譯器有關(guān)。
1.1.7 有了malloc/free為什么還要new/delete？
malloc與free是C++/C語(yǔ)言的標(biāo)準(zhǔn)庫(kù)函數(shù)，new/delete是C++的運(yùn)算符。它們都可用于申請(qǐng)動(dòng)態(tài)內(nèi)存和釋放內(nèi)存。
對(duì)于非內(nèi)部數(shù)據(jù)類型的對(duì)象而言，光用maloc/free無(wú)法滿足動(dòng)態(tài)對(duì)象的要求。對(duì)象在創(chuàng)建的同時(shí)要自動(dòng)執(zhí)行構(gòu)造函數(shù)，對(duì)象在消亡之前要自動(dòng)執(zhí)行析構(gòu)函數(shù)。由于malloc/free是庫(kù)函數(shù)而不是運(yùn)算符，不在編譯器控制權(quán)限之內(nèi)，不能夠把執(zhí)行構(gòu)造函數(shù)和析構(gòu)函數(shù)的任務(wù)強(qiáng)加于malloc/free。
因此C++語(yǔ)言需要一個(gè)能完成動(dòng)態(tài)內(nèi)存分配和初始化工作的運(yùn)算符new，以及一個(gè)能完成清理與釋放內(nèi)存工作的運(yùn)算符delete。注意new/delete不是庫(kù)函數(shù)。我們先看一看malloc/free和new/delete如何實(shí)現(xiàn)對(duì)象的動(dòng)態(tài)內(nèi)存管理，見示例：
| class Obj { public : Obj(void){ cout << “Initialization” << endl; } ~Obj(void){ cout << “Destroy” << endl; } void Initialize(void){ cout << “Initialization” << endl; } void Destroy(void){ cout << “Destroy” << endl; } }; void UseMallocFree(void) { Obj *a = (obj *)malloc(sizeof(obj)); // 申請(qǐng)動(dòng)態(tài)內(nèi)存 a->Initialize(); // 初始化 //… a->Destroy(); // 清除工作 free(a); // 釋放內(nèi)存 } void UseNewDelete(void) { Obj *a = new Obj; // 申請(qǐng)動(dòng)態(tài)內(nèi)存并且初始化 //… delete a; // 清除并且釋放內(nèi)存 } |
類Obj的函數(shù)Initialize模擬了構(gòu)造函數(shù)的功能，函數(shù)Destroy模擬了析構(gòu)函數(shù)的功能。函數(shù)UseMallocFree中，由于malloc/free不能執(zhí)行構(gòu)造函數(shù)與析構(gòu)函數(shù)，必須調(diào)用成員函數(shù)Initialize和Destroy來(lái)完成初始化與清除工作。函數(shù)UseNewDelete則簡(jiǎn)單得多。
所以我們不要企圖用malloc/free來(lái)完成動(dòng)態(tài)對(duì)象的內(nèi)存管理，應(yīng)該用new/delete。由于內(nèi)部數(shù)據(jù)類型的“對(duì)象”沒有構(gòu)造與析構(gòu)的過程，對(duì)它們而言malloc/free和new/delete是等價(jià)的。
既然new/delete的功能完全覆蓋了malloc/free，為什么C++不把malloc/free淘汰出局呢？這是因?yàn)镃++程序經(jīng)常要調(diào)用C函數(shù)，而C程序只能用malloc/free管理動(dòng)態(tài)內(nèi)存。
如果用free釋放“new創(chuàng)建的動(dòng)態(tài)對(duì)象”，那么該對(duì)象因無(wú)法執(zhí)行析構(gòu)函數(shù)而可能導(dǎo)致程序出錯(cuò)。如果用delete釋放“malloc申請(qǐng)的動(dòng)態(tài)內(nèi)存”，結(jié)果也會(huì)導(dǎo)致程序出錯(cuò)，但是該程序的可讀性很差。所以new/delete必須配對(duì)使用，malloc/free也一樣。
1.1.8 內(nèi)存耗盡怎么辦？
如果在申請(qǐng)動(dòng)態(tài)內(nèi)存時(shí)找不到足夠大的內(nèi)存塊，malloc和new將返回NULL指針，宣告內(nèi)存申請(qǐng)失敗。通常有三種方式處理“內(nèi)存耗盡”問題。
（1）判斷指針是否為NULL，如果是則馬上用return語(yǔ)句終止本函數(shù)。例如：
| void Func(void) { A *a = new A; if(a == NULL) { return; } … } |
�。�2）判斷指針是否為NULL，如果是則馬上用exit(1)終止整個(gè)程序的運(yùn)行。例如：
| void Func(void) { A *a = new A; if(a == NULL) { cout << “Memory Exhausted” << endl; exit(1); } … } |
（3）為new和malloc設(shè)置異常處理函數(shù)。例如Visual C++可以用_set_new_hander函數(shù)為new設(shè)置用戶自己定義的異常處理函數(shù)，也可以讓malloc享用與new相同的異常處理函數(shù)。詳細(xì)內(nèi)容請(qǐng)參考C++使用手冊(cè)。
上述（1）（2）方式使用最普遍。如果一個(gè)函數(shù)內(nèi)有多處需要申請(qǐng)動(dòng)態(tài)內(nèi)存，那么方式（1）就顯得力不從心（釋放內(nèi)存很麻煩），應(yīng)該用方式（2）來(lái)處理。
很多人不忍心用exit(1)，問：“不編寫出錯(cuò)處理程序，讓操作系統(tǒng)自己解決行不行？”
不行。如果發(fā)生“內(nèi)存耗盡”這樣的事情，一般說來(lái)應(yīng)用程序已經(jīng)無(wú)藥可救。如果不用exit(1) 把壞程序殺死，它可能會(huì)害死操作系統(tǒng)。道理如同：如果不把歹徒擊斃，歹徒在老死之前會(huì)犯下更多的罪。
有一個(gè)很重要的現(xiàn)象要告訴大家。對(duì)于32位以上的應(yīng)用程序而言，無(wú)論怎樣使用malloc與new，幾乎不可能導(dǎo)致“內(nèi)存耗盡”。我在Windows 98下用Visual C++編寫了測(cè)試程序，見示例7。這個(gè)程序會(huì)無(wú)休止地運(yùn)行下去，根本不會(huì)終止。因?yàn)?2位操作系統(tǒng)支持“虛存”，內(nèi)存用完了，自動(dòng)用硬盤空間頂替。我只聽到硬盤嘎吱嘎吱地響，Window 98已經(jīng)累得對(duì)鍵盤、鼠標(biāo)毫無(wú)反應(yīng)。
我可以得出這么一個(gè)結(jié)論：對(duì)于32位以上的應(yīng)用程序，“內(nèi)存耗盡”錯(cuò)誤處理程序毫無(wú)用處。這下可把Unix和Windows程序員們樂壞了：反正錯(cuò)誤處理程序不起作用，我就不寫了，省了很多麻煩。
我不想誤導(dǎo)讀者，必須強(qiáng)調(diào)：不加錯(cuò)誤處理將導(dǎo)致程序的質(zhì)量很差，千萬(wàn)不可因小失大。
| void main(void) { float *p = NULL; while(TRUE) { p = new float[1000000]; cout << “eat memory” << endl; if(p==NULL) exit(1); } } |
1.1.9 malloc/free的使用要點(diǎn)
函數(shù)malloc的原型如下：
| void * malloc(size_t size); |
用malloc申請(qǐng)一塊長(zhǎng)度為length的整數(shù)類型的內(nèi)存，程序如下：
| int *p = (int *) malloc(sizeof(int) * length); |
我們應(yīng)當(dāng)把注意力集中在兩個(gè)要素上：“類型轉(zhuǎn)換”和“sizeof”。
* malloc返回值的類型是void *，所以在調(diào)用malloc時(shí)要顯式地進(jìn)行類型轉(zhuǎn)換，將void * 轉(zhuǎn)換成所需要的指針類型。
* malloc函數(shù)本身并不識(shí)別要申請(qǐng)的內(nèi)存是什么類型，它只關(guān)心內(nèi)存的總字節(jié)數(shù)。我們通常記不住int, float等數(shù)據(jù)類型的變量的確切字節(jié)數(shù)。例如int變量在16位系統(tǒng)下是2個(gè)字節(jié)，在32位下是4個(gè)字節(jié)；而float變量在16位系統(tǒng)下是4個(gè)字節(jié)，在32位下也是4個(gè)字節(jié)。最好用以下程序作一次測(cè)試：
| cout << sizeof(char) << endl; cout << sizeof(int) << endl; cout << sizeof(unsigned int) << endl; cout << sizeof(long) << endl; cout << sizeof(unsigned long) << endl; cout << sizeof(float) << endl; cout << sizeof(double) << endl; cout << sizeof(void *) << endl; |
在malloc的“()”中使用sizeof運(yùn)算符是良好的風(fēng)格，但要當(dāng)心有時(shí)我們會(huì)昏了頭，寫出 p = malloc(sizeof(p))這樣的程序來(lái)。
函數(shù)free的原型如下：
| void free( void * memblock ); |
為什么free函數(shù)不象malloc函數(shù)那樣復(fù)雜呢？這是因?yàn)橹羔榩的類型以及它所指的內(nèi)存的容量事先都是知道的，語(yǔ)句free(p)能正確地釋放內(nèi)存。如果p是NULL指針，那么free對(duì)p無(wú)論操作多少次都不會(huì)出問題。如果p不是NULL指針，那么free對(duì)p連續(xù)操作兩次就會(huì)導(dǎo)致程序運(yùn)行錯(cuò)誤。
1.1.10 new/delete的使用要點(diǎn)
運(yùn)算符new使用起來(lái)要比函數(shù)malloc簡(jiǎn)單得多，例如：
| int *p1 = (int *)malloc(sizeof(int) * length); int *p2 = new int[length]; |
這是因?yàn)閚ew內(nèi)置了sizeof、類型轉(zhuǎn)換和類型安全檢查功能。對(duì)于非內(nèi)部數(shù)據(jù)類型的對(duì)象而言，new在創(chuàng)建動(dòng)態(tài)對(duì)象的同時(shí)完成了初始化工作。如果對(duì)象有多個(gè)構(gòu)造函數(shù)，那么new的語(yǔ)句也可以有多種形式。例如
| class Obj { public : Obj(void); // 無(wú)參數(shù)的構(gòu)造函數(shù) Obj(int x); // 帶一個(gè)參數(shù)的構(gòu)造函數(shù) … } void Test(void) { Obj *a = new Obj; Obj *b = new Obj(1); // 初值為1 … delete a; delete b; } |
如果用new創(chuàng)建對(duì)象數(shù)組，那么只能使用對(duì)象的無(wú)參數(shù)構(gòu)造函數(shù)。例如：
| Obj *objects = new Obj[100]; // 創(chuàng)建100個(gè)動(dòng)態(tài)對(duì)象 |
不能寫成：
| Obj *objects = new Obj[100](1);// 創(chuàng)建100個(gè)動(dòng)態(tài)對(duì)象的同時(shí)賦初值1 |
在用delete釋放對(duì)象數(shù)組時(shí)，留意不要丟了符號(hào)‘[]’。例如：
| delete []objects; // 正確的用法 delete objects; // 錯(cuò)誤的用法 |
后者有可能引起程序崩潰和內(nèi)存泄漏。
1.2 C++中的健壯指針和資源管理
我最喜歡的對(duì)資源的定義是："任何在你的程序中獲得并在此后釋放的東西?quot;內(nèi)存是一個(gè)相當(dāng)明顯的資源的例子。它需要用new來(lái)獲得，用delete來(lái)釋放。同時(shí)也有許多其它類型的資源文件句柄、重要的片斷、Windows中的GDI資源，等等。將資源的概念推廣到程序中創(chuàng)建、釋放的所有對(duì)象也是十分方便的，無(wú)論對(duì)象是在堆中分配的還是在棧中或者是在全局作用于內(nèi)生命的。
對(duì)于給定的資源的擁有著，是負(fù)責(zé)釋放資源的一個(gè)對(duì)象或者是一段代碼。所有權(quán)分立為兩種級(jí)別——自動(dòng)的和顯式的（automatic and explicit），如果一個(gè)對(duì)象的釋放是由語(yǔ)言本身的機(jī)制來(lái)保證的，這個(gè)對(duì)象的就是被自動(dòng)地所有。例如，一個(gè)嵌入在其他對(duì)象中的對(duì)象，他的清除需要其他對(duì)象來(lái)在清除的時(shí)候保證。外面的對(duì)象被看作嵌入類的所有者。 類似地，每個(gè)在棧上創(chuàng)建的對(duì)象（作為自動(dòng)變量）的釋放（破壞）是在控制流離開了對(duì)象被定義的作用域的時(shí)候保證的。這種情況下，作用于被看作是對(duì)象的所有者。注意所有的自動(dòng)所有權(quán)都是和語(yǔ)言的其他機(jī)制相容的，包括異常。無(wú)論是如何退出作用域的——正常流程控制退出、一個(gè)break語(yǔ)句、一個(gè)return、一個(gè)goto、或者是一個(gè)throw——自動(dòng)資源都可以被清除。
到目前為止，一切都很好！問題是在引入指針、句柄和抽象的時(shí)候產(chǎn)生的。如果通過一個(gè)指針訪問一個(gè)對(duì)象的話，比如對(duì)象在堆中分配，C++不自動(dòng)地關(guān)注它的釋放。程序員必須明確的用適當(dāng)?shù)某绦蚍椒▉?lái)釋放這些資源。比如說，如果一個(gè)對(duì)象是通過調(diào)用new來(lái)創(chuàng)建的，它需要用delete來(lái)回收。一個(gè)文件是用CreateFile(Win32 API)打開的，它需要用CloseHandle來(lái)關(guān)閉。用EnterCritialSection進(jìn)入的臨界區(qū)（Critical Section）需要LeaveCriticalSection退出，等等。一個(gè)"裸"指針，文件句柄，或者臨界區(qū)狀態(tài)沒有所有者來(lái)確保它們的最終釋放�；镜馁Y源管理的前提就是確保每個(gè)資源都有他們的所有者。
1.2.1 第一條規(guī)則（RAII）
一個(gè)指針，一個(gè)句柄，一個(gè)臨界區(qū)狀態(tài)只有在我們將它們封裝入對(duì)象的時(shí)候才會(huì)擁有所有者。這就是我們的第一規(guī)則：在構(gòu)造函數(shù)中分配資源，在析構(gòu)函數(shù)中釋放資源。
當(dāng)你按照規(guī)則將所有資源封裝的時(shí)候，你可以保證你的程序中沒有任何的資源泄露。這點(diǎn)在當(dāng)封裝對(duì)象（Encapsulating Object） 在棧中建立或者嵌入在其他的對(duì)象中的時(shí)候非常明顯。但是對(duì)那些動(dòng)態(tài)申請(qǐng)的對(duì)象呢？不要急！任何動(dòng)態(tài)申請(qǐng)的東西都被看作一種資源，并且要按照上面提到的方法 進(jìn)行封裝。這一對(duì)象封裝對(duì)象的鏈不得不在某個(gè)地方終止。它最終終止在最高級(jí)的所有者，自動(dòng)的或者是靜態(tài)的。這些分別是對(duì)離開作用域或者程序時(shí)釋放資源的保 證。
下面是資源封裝的一個(gè)經(jīng)典例子。在一個(gè)多線程的應(yīng)用程序中，線程之間共享對(duì)象的問題是通過用這樣一個(gè)對(duì)象聯(lián)系臨界區(qū)來(lái)解決的。每一個(gè)需要訪問共享資源的客戶需要獲得臨界區(qū)。例如，這可能是Win32下臨界區(qū)的實(shí)現(xiàn)方法。
| class CritSect { friend class Lock; public: CritSect () { InitializeCriticalSection (&_critSection); } ~CritSect () { DeleteCriticalSection (&_critSection); } private: void Acquire () { EnterCriticalSection (&_critSection); } void Release () { LeaveCriticalSection (&_critSection); } private: CRITICAL_SECTION _critSection; }; |
這里聰明的部分是我們確保每一個(gè)進(jìn)入臨界區(qū)的客戶最后都可以離開。"進(jìn)入"臨界區(qū)的狀態(tài)是一種資源，并應(yīng)當(dāng)被封裝。封裝器通常被稱作一個(gè)鎖（lock）。
| class Lock { public: Lock (CritSect& critSect) : _critSect (critSect) { _critSect.Acquire (); } ~Lock () { _critSect.Release (); } private CritSect & _critSect; }; |
鎖一般的用法如下：
| void Shared::Act () throw (char *) { Lock lock (_critSect); // perform action —— may throw // automatic destructor of lock } |
注意無(wú)論發(fā)生什么，臨界區(qū)都會(huì)借助于語(yǔ)言的機(jī)制保證釋放。
還有一件需要記住的事情——每一種資源都需要被分別封裝。這是因?yàn)橘Y源分配是一 個(gè)非常容易出錯(cuò)的操作，是要資源是有限提供的。我們會(huì)假設(shè)一個(gè)失敗的資源分配會(huì)導(dǎo)致一個(gè)異�！聦�(shí)上，這會(huì)經(jīng)常的發(fā)生。所以如果你想試圖用一個(gè)石頭打兩 只鳥的話，或者在一個(gè)構(gòu)造函數(shù)中申請(qǐng)兩種形式的資源，你可能就會(huì)陷入麻煩。只要想想在一種資源分配成功但另一種失敗拋出異常時(shí)會(huì)發(fā)生什么。因?yàn)闃?gòu)造函數(shù)還 沒有全部完成，析構(gòu)函數(shù)不可能被調(diào)用，第一種資源就會(huì)發(fā)生泄露。
這種情況可以非常簡(jiǎn)單的避免。無(wú)論何時(shí)你有一個(gè)需要兩種以上資源的類時(shí)，寫兩個(gè)小的封裝器將它們嵌入你的類中。每一個(gè)嵌入的構(gòu)造都可以保證刪除，即使包裝類沒有構(gòu)造完成。
1.2.2 Smart Pointers
我們至今還沒有討論最常見類型的資源——用操作符new分配，此后用指針訪問的一個(gè)對(duì)象。我們需要為每個(gè)對(duì)象分別定義一個(gè)封裝類嗎？（事實(shí)上，C++標(biāo)準(zhǔn)模板庫(kù)已經(jīng)有了一個(gè)模板類，叫做auto_ptr，其作用就是提供這種封裝。我們一會(huì)兒在回到auto_ptr。）讓我們從一個(gè)極其簡(jiǎn)單、呆板但安全的東西開始�？聪旅娴腟mart Pointer模板類，它十分堅(jiān)固，甚至無(wú)法實(shí)現(xiàn)。
| template <class T> class SmartPointer { public: ~SmartPointer () { delete _p; } T * operator->() { return _p; } T const * operator->() const { return _p; } protected: SmartPointer (): _p (0) {} explicit SmartPointer (T* p): _p (p) {} T * _p; }; |
為什么要把SmartPointer的構(gòu)造函數(shù)設(shè)計(jì)為protected呢？如果我需要遵守第一條規(guī)則，那么我就必須這樣做。資源——在這里是class T的一個(gè)對(duì)象——必須在封裝器的構(gòu)造函數(shù)中分配。但是我不能只簡(jiǎn)單的調(diào)用new T，因?yàn)槲也恢繲的構(gòu)造函數(shù)的參數(shù)。因?yàn)�，在原則上，每一個(gè)T都有一個(gè)不同的構(gòu)造函數(shù)；我需要為他定義個(gè)另外一個(gè)封裝器。模板的用處會(huì)很大，為每一個(gè)新的類，我可以通過繼承SmartPointer定義一個(gè)新的封裝器，并且提供一個(gè)特定的構(gòu)造函數(shù)。
| class SmartItem: public SmartPointer<Item> { public: explicit SmartItem (int i) : SmartPointer<Item> (new Item (i)) {} }; |
為每一個(gè)類提供一個(gè)Smart Pointer真的值得嗎？說實(shí)話——不！他很有教學(xué)的價(jià)值，但是一旦你學(xué)會(huì)如何遵循第一規(guī)則的話，你就可以放松規(guī)則并使用一些高級(jí)的技術(shù)。這一技術(shù)是讓SmartPointer的構(gòu)造函數(shù)成為public，但是只是是用它來(lái)做資源轉(zhuǎn)換（Resource Transfer）我的意思是用new操作符的結(jié)果直接作為SmartPointer的構(gòu)造函數(shù)的參數(shù)，像這樣：
| SmartPointer<Item> item (new Item (i)); |
這個(gè)方法明顯更需要自控性，不只是你，而且包括你的程序小組的每個(gè)成員。他們都必須發(fā)誓出了作資源轉(zhuǎn)換外不把構(gòu)造函數(shù)用在人以其他用途。幸運(yùn)的是，這條規(guī)矩很容易得以加強(qiáng)。只需要在源文件中查找所有的new即可。
1.2.3 Resource Transfer
到目前為止，我們所討論的一直是生命周期在一個(gè)單獨(dú)的作用域內(nèi)的資源。現(xiàn)在我們 要解決一個(gè)困難的問題——如何在不同的作用域間安全的傳遞資源。這一問題在當(dāng)你處理容器的時(shí)候會(huì)變得十分明顯。你可以動(dòng)態(tài)的創(chuàng)建一串對(duì)象，將它們存放至一 個(gè)容器中，然后將它們?nèi)〕�，并且在最終安排它們。為了能夠讓這安全的工作——沒有泄露——對(duì)象需要改變其所有者。
這個(gè)問題的一個(gè)非常顯而易見的解決方法是使用Smart Pointer，無(wú)論是在加入容器前還是還找到它們以后。這是他如何運(yùn)作的，你加入Release方法到Smart Pointer中：
| template <class T> T * SmartPointer<T>::Release () { T * pTmp = _p; _p = 0; return pTmp; } |
注意在Release調(diào)用以后，Smart Pointer就不再是對(duì)象的所有者了——它內(nèi)部的指針指向空�，F(xiàn)在，調(diào)用了Release都必須是一個(gè)負(fù)責(zé)的人并且迅速隱藏返回的指針到新的所有者對(duì)象中。在我們的例子中，容器調(diào)用了Release，比如這個(gè)Stack的例子：
| void Stack::Push (SmartPointer <Item> & item) throw (char *) { if (_top == maxStack) throw "Stack overflow"; _arr [_top++] = item.Release (); }; |
同樣的，你也可以再你的代碼中用加強(qiáng)Release的可靠性。
相應(yīng)的Pop方法要做些什么呢？他應(yīng)該釋放了資源并祈禱調(diào)用它的是一個(gè)負(fù)責(zé)的人而且立即作一個(gè)資源傳遞它到一個(gè)Smart Pointer？這聽起來(lái)并不好。
1.2.4 Strong Pointers
資源管理在內(nèi)容索引（Windows NT Server上的一部分，現(xiàn)在是Windows 2000）上工作，并且，我對(duì)這十分滿意。然后我開始想……這一方法是在這樣一個(gè)完整的系統(tǒng)中形成的，如果可以把它內(nèi)建入語(yǔ)言的本身豈不是一件非常好？我提出了強(qiáng)指針（Strong Pointer）和弱指針(Weak Pointer)。一個(gè)Strong Pointer會(huì)在許多地方和我們這個(gè)SmartPointer相似--它在超出它的作用域后會(huì)清除他所指向的對(duì)象。資源傳遞會(huì)以強(qiáng)指針賦值的形式進(jìn)行。也可以有Weak Pointer存在，它們用來(lái)訪問對(duì)象而不需要所有對(duì)象--比如可賦值的引用。
任何指針都必須聲明為Strong或者Weak，并且語(yǔ)言應(yīng)該來(lái)關(guān)注類型轉(zhuǎn)換的規(guī)定。例如，你不可以將Weak Pointer傳遞到一個(gè)需要Strong Pointer的地方，但是相反卻可以。Push方法可以接受一個(gè)Strong Pointer并且將它轉(zhuǎn)移到Stack中的Strong Pointer的序列中。Pop方法將會(huì)返回一個(gè)Strong Pointer。把Strong Pointer的引入語(yǔ)言將會(huì)使垃圾回收成為歷史。
這里還有一個(gè)小問題--修改C++標(biāo)準(zhǔn)幾乎和競(jìng)選美國(guó)總統(tǒng)一樣容易。當(dāng)我將我的注意告訴給Bjarne Stroutrup的時(shí)候，他看我的眼神好像是我剛剛要向他借一千美元一樣。
然后我突然想到一個(gè)念頭。我可以自己實(shí)現(xiàn)Strong Pointers。畢竟，它們都很想Smart Pointers。給它們一個(gè)拷貝構(gòu)造函數(shù)并重載賦值操作符并不是一個(gè)大問題。事實(shí)上，這正是標(biāo)準(zhǔn)庫(kù)中的auto_ptr有的。重要的是對(duì)這些操作給出一個(gè)資源轉(zhuǎn)移的語(yǔ)法，但是這也不是很難。
| template <class T> SmartPointer<T>::SmartPointer (SmartPointer<T> & ptr) { _p = ptr.Release (); } template <class T> void SmartPointer<T>::operator = (SmartPointer<T> & ptr) { if (_p != ptr._p) { delete _p; _p = ptr.Release (); } } |
使這整個(gè)想法迅速成功的原因之一是我可以以值方式傳遞這種封裝指針！我有了我的蛋糕，并且也可以吃了。看這個(gè)Stack的新的實(shí)現(xiàn)：
| class Stack { enum { maxStack = 3 }; public: Stack () : _top (0) {} void Push (SmartPointer<Item> & item) throw (char *) { if (_top >= maxStack) throw "Stack overflow"; _arr [_top++] = item; } SmartPointer<Item> Pop () { if (_top == 0) return SmartPointer<Item> (); return _arr [--_top]; } private int _top; SmartPointer<Item> _arr [maxStack]; }; |
Pop方法強(qiáng)制客戶將其返回值賦給一個(gè)Strong Pointer,SmartPointer<Item>。任何試圖將他對(duì)一個(gè)普通指針的賦值都會(huì)產(chǎn)生一個(gè)編譯期錯(cuò)誤，因?yàn)轭愋筒黄ヅ洹４送�，因�(yàn)镻op以值方式返回一個(gè)Strong Pointer(在Pop的聲明時(shí)SmartPointer<Item>后面沒有&符號(hào))，編譯器在return時(shí)自動(dòng)進(jìn)行了一個(gè)資源轉(zhuǎn)換。他調(diào)用了operator =來(lái)從數(shù)組中提取一個(gè)Item,拷貝構(gòu)造函數(shù)將他傳遞給調(diào)用者。調(diào)用者最后擁有了指向Pop賦值的Strong Pointer指向的一個(gè)Item。
我馬上意識(shí)到我已經(jīng)在某些東西之上了。我開始用了新的方法重寫原來(lái)的代碼。
1.2.5 Parser
我過去有一個(gè)老的算術(shù)操作分析器，是用老的資源管理的技術(shù)寫的。分析器的作用是在分析樹中生成節(jié)點(diǎn)，節(jié)點(diǎn)是動(dòng)態(tài)分配的。例如分析器的Expression方法生成一個(gè)表達(dá)式節(jié)點(diǎn)。我沒有時(shí)間用Strong Pointer去重寫這個(gè)分析器。我令Expression、Term和Factor方法以傳值的方式將Strong Pointer返回到Node中�？聪旅娴腅xpression方法的實(shí)現(xiàn)：
| SmartPointer<Node> Parser::Expression() { // Parse a term SmartPointer<Node> pNode = Term (); EToken token = _scanner.Token(); if ( token == tPlus || token == tMinus ) { // Expr := Term { ('+' | '-') Term } SmartPointer<MultiNode> pMultiNode = new SumNode (pNode); do { _scanner.Accept(); SmartPointer<Node> pRight = Term (); pMultiNode->AddChild (pRight, (token == tPlus)); token = _scanner.Token(); } while (token == tPlus || token == tMinus); pNode = up_cast<Node, MultiNode> (pMultiNode); } // otherwise Expr := Term return pNode; // by value! } |
最開始，Term方法被調(diào)用。他傳值返回一個(gè)指向Node的Strong Pointer并且立刻把它保存到我們自己的Strong Pointer,pNode中。如果下一個(gè)符號(hào)不是加號(hào)或者減號(hào)，我們就簡(jiǎn)單的把這個(gè)SmartPointer以值返回，這樣就釋放了Node的所有權(quán)。另外一方面，如果下一個(gè)符號(hào)是加號(hào)或者減號(hào)，我們創(chuàng)建一個(gè)新的SumMode并且立刻（直接傳遞）將它儲(chǔ)存到MultiNode的一個(gè)Strong Pointer中。這里，SumNode是從MultiMode中繼承而來(lái)的，而MulitNode是從Node繼承而來(lái)的。原來(lái)的Node的所有權(quán)轉(zhuǎn)給了SumNode。
只要是他們?cè)诒患犹?hào)和減號(hào)分開的時(shí)候，我們就不斷的創(chuàng)建terms，我們將這些term轉(zhuǎn)移到我們的MultiNode中，同時(shí)MultiNode得到了所有權(quán)。最后，我們將指向MultiNode的Strong Pointer向上映射為指向Mode的Strong Pointer，并且將他返回調(diào)用著。
我們需要對(duì)Strong Pointers進(jìn)行顯式的向上映射，即使指針是被隱式的封裝。例如，一個(gè)MultiNode是一個(gè)Node，但是相同的is-a關(guān)系在SmartPointer<MultiNode>和SmartPointer<Node>之間并不存在，因?yàn)樗鼈兪欠蛛x的類（模板實(shí)例）并不存在繼承關(guān)系。up-cast模板是像下面這樣定義的：
| template<class To, class From> inline SmartPointer<To> up_cast (SmartPointer<From> & from) { return SmartPointer<To> (from.Release ()); } |
如果你的編譯器支持新加入標(biāo)準(zhǔn)的成員模板（member template）的話，你可以為SmartPointer<T>定義一個(gè)新的構(gòu)造函數(shù)用來(lái)從接受一個(gè)class U。
| template <class T> template <class U> SmartPointer<T>::SmartPointer (SPrt<U> & uptr) : _p (uptr.Release ()) {} |
這里的這個(gè)花招是模板在U不是T的子類的時(shí)候就不會(huì)編譯成功（換句話說，只在U is-a T的時(shí)候才會(huì)編譯）。這是因?yàn)閡ptr的緣故。Release()方法返回一個(gè)指向U的指針，并被賦值為_p，一個(gè)指向T的指針。所以如果U不是一個(gè)T的話，賦值會(huì)導(dǎo)致一個(gè)編譯時(shí)刻錯(cuò)誤。
| std::auto_ptr |
后來(lái)我意識(shí)到在STL中的auto_ptr模板，就是我的Strong Pointer。在那時(shí)候還有許多的實(shí)現(xiàn)差異（auto_ptr的Release方法并不將內(nèi)部的指針清零--你的編譯器的庫(kù)很可能用的就是這種陳舊的實(shí)現(xiàn)），但是最后在標(biāo)準(zhǔn)被廣泛接受之前都被解決了。
1.2.6 Transfer Semantics
目前為止，我們一直在討論在C++程序中資源管理的方法。宗旨是將資源封裝到一些輕量級(jí)的類中，并由類負(fù)責(zé)它們的釋放。特別的是，所有用new操作符分配的資源都會(huì)被儲(chǔ)存并傳遞進(jìn)Strong Pointer（標(biāo)準(zhǔn)庫(kù)中的auto_ptr）的內(nèi)部。
這里的關(guān)鍵詞是傳遞（passing）。一個(gè)容器可以通過傳值返回一個(gè)Strong Pointer來(lái)安全的釋放資源。容器的客戶只能夠通過提供一個(gè)相應(yīng)的Strong Pointer來(lái)保存這個(gè)資源。任何一個(gè)將結(jié)果賦給一個(gè)"裸"指針的做法都立即會(huì)被編譯器發(fā)現(xiàn)。
| auto_ptr<Item> item = stack.Pop (); // ok Item * p = stack.Pop (); // Error! Type mismatch. |
以傳值方式被傳遞的對(duì)象有value semantics 或者稱為 copy semantics。Strong Pointers是以值方式傳遞的--但是我們能說它們有copy semantics嗎？不是這樣的！它們所指向的對(duì)象肯定沒有被拷貝過。事實(shí)上，傳遞過后，源auto_ptr不在訪問原有的對(duì)象，并且目標(biāo)auto_ptr成為了對(duì)象的唯一擁有者（但是往往auto_ptr的舊的實(shí)現(xiàn)即使在釋放后仍然保持著對(duì)對(duì)象的所有權(quán)）。自然而然的我們可以將這種新的行為稱作Transfer Semantics。
拷貝構(gòu)造函數(shù)（copy construcor）和賦值操作符定義了auto_ptr的Transfer Semantics，它們用了非const的auto_ptr引用作為它們的參數(shù)。
| auto_ptr (auto_ptr<T> & ptr); auto_ptr & operator = (auto_ptr<T> & ptr); |
這是因?yàn)樗鼈兇_實(shí)改變了他們的源--剝奪了對(duì)資源的所有權(quán)。
通過定義相應(yīng)的拷貝構(gòu)造函數(shù)和重載賦值操作符，你可以將Transfer Semantics加入到許多對(duì)象中。例如，許多Windows中的資源，比如動(dòng)態(tài)建立的菜單或者位圖，可以用有Transfer Semantics的類來(lái)封裝。
1.2.7 Strong Vectors
標(biāo)準(zhǔn)庫(kù)只在auto_ptr中支持資源管理。甚至連最簡(jiǎn)單的容器也不支持ownership semantics。你可能想將auto_ptr和標(biāo)準(zhǔn)容器組合到一起可能會(huì)管用，但是并不是這樣的。例如，你可能會(huì)這樣做，但是會(huì)發(fā)現(xiàn)你不能夠用標(biāo)準(zhǔn)的方法來(lái)進(jìn)行索引。
| vector< auto_ptr<Item> > autoVector; |
這種建造不會(huì)編譯成功；
| Item * item = autoVector [0]; |
另一方面，這會(huì)導(dǎo)致一個(gè)從autoVect到auto_ptr的所有權(quán)轉(zhuǎn)換：
| auto_ptr<Item> item = autoVector [0]; |
我們沒有選擇，只能夠構(gòu)造我們自己的Strong Vector。最小的接口應(yīng)該如下：
| template <class T> class auto_vector { public: explicit auto_vector (size_t capacity = 0); T const * operator [] (size_t i) const; T * operator [] (size_t i); void assign (size_t i, auto_ptr<T> & p); void assign_direct (size_t i, T * p); void push_back (auto_ptr<T> & p); auto_ptr<T> pop_back (); }; |
你也許會(huì)發(fā)現(xiàn)一個(gè)非常防御性的設(shè)計(jì)態(tài)度。我決定不提供一個(gè)對(duì)vector的左值索引的訪問，取而代之，如果你想設(shè)定(set)一個(gè)值的話，你必須用assign或者assign_direct方法。我的觀點(diǎn)是，資源管理不應(yīng)該被忽視，同時(shí)，也不應(yīng)該在所有的地方濫用。在我的經(jīng)驗(yàn)里，一個(gè)strong vector經(jīng)常被許多push_back方法充斥著。
Strong vector最好用一個(gè)動(dòng)態(tài)的Strong Pointers的數(shù)組來(lái)實(shí)現(xiàn)：
| template <class T> class auto_vector { private void grow (size_t reqCapacity); auto_ptr<T> *_arr; size_t _capacity; size_t _end; }; |
grow方法申請(qǐng)了一個(gè)很大的auto_ptr<T>的數(shù)組，將所有的東西從老的書組類轉(zhuǎn)移出來(lái)，在其中交換，并且刪除原來(lái)的數(shù)組。
auto_vector的其他實(shí)現(xiàn)都是十分直接的，因?yàn)樗匈Y源管理的復(fù)雜度都在auto_ptr中。例如，assign方法簡(jiǎn)單的利用了重載的賦值操作符來(lái)刪除原有的對(duì)象并轉(zhuǎn)移資源到新的對(duì)象：
| void assign (size_t i, auto_ptr<T> & p) { _arr [i] = p; } |
我已經(jīng)討論了push_back和pop_back方法。push_back方法傳值返回一個(gè)auto_ptr，因?yàn)樗鼘⑺袡?quán)從auto_vector轉(zhuǎn)換到auto_ptr中。
對(duì)auto_vector的索引訪問是借助auto_ptr的get方法來(lái)實(shí)現(xiàn)的，get簡(jiǎn)單的返回一個(gè)內(nèi)部指針。
| T * operator [] (size_t i) { return _arr [i].get (); } |
沒有容器可以沒有iterator。我們需要一個(gè)iterator讓auto_vector看起來(lái)更像一個(gè)普通的指針向量。特別是，當(dāng)我們廢棄iterator的時(shí)候，我們需要的是一個(gè)指針而不是auto_ptr。我們不希望一個(gè)auto_vector的iterator在無(wú)意中進(jìn)行資源轉(zhuǎn)換。
| template<class T> class auto_iterator: public iterator<random_access_iterator_tag, T *> { public: auto_iterator () : _pp (0) {} auto_iterator (auto_ptr<T> * pp) : _pp (pp) {} bool operator != (auto_iterator<T> const & it) const { return it._pp != _pp; } auto_iterator const & operator++ (int) { return _pp++; } auto_iterator operator++ () { return ++_pp; } T * operator * () { return _pp->get (); } private auto_ptr<T> * _pp; }; |
我們給auto_vect提供了標(biāo)準(zhǔn)的begin和end方法來(lái)找回iterator：
| class auto_vector { public: typedef auto_iterator<T> iterator; iterator begin () { return _arr; } iterator end () { return _arr + _end; } }; |
你也許會(huì)問我們是否要利用資源管理重新實(shí)現(xiàn)每一個(gè)標(biāo)準(zhǔn)的容器？幸運(yùn)的是，不;事實(shí)是strong vector解決了大部分所有權(quán)的需求。當(dāng)你把你的對(duì)象都安全的放置到一個(gè)strong vector中，你可以用所有其它的容器來(lái)重新安排（weak）pointer。
設(shè)想，例如，你需要對(duì)一些動(dòng)態(tài)分配的對(duì)象排序的時(shí)候。你將它們的指針保存到一個(gè)strong vector中。然后你用一個(gè)標(biāo)準(zhǔn)的vector來(lái)保存從strong vector中獲得的weak指針。你可以用標(biāo)準(zhǔn)的算法對(duì)這個(gè)vector進(jìn)行排序。這種中介vector叫做permutation vector。相似的，你也可以用標(biāo)準(zhǔn)的maps, priority queues, heaps, hash tables等等。
1.2.8 Code Inspection
如果你嚴(yán)格遵照資源管理的條款，你就不會(huì)再資源泄露或者兩次刪除的地方遇到麻煩。你也降低了訪問野指針的幾率。同樣的，遵循原有的規(guī)則，用delete刪除用new申請(qǐng)的德指針，不要兩次刪除一個(gè)指針。你也不會(huì)遇到麻煩。但是，那個(gè)是更好的注意呢？
這兩個(gè)方法有一個(gè)很大的不同點(diǎn)。就是和尋找傳統(tǒng)方法的bug相比，找到違反資源管理的規(guī)定要容易的多。后者僅需要一個(gè)代碼檢測(cè)或者一個(gè)運(yùn)行測(cè)試，而前者則在代碼中隱藏得很深，并需要很深的檢查。
設(shè)想你要做一段傳統(tǒng)的代碼的內(nèi)存泄露檢查。第一件事，你要做的就是grep所有在代碼中出現(xiàn)的new，你需要找出被分配空間地指針都作了什么。你需要確定導(dǎo)致刪除這個(gè)指針的所有的執(zhí)行路徑。你需要檢查break語(yǔ)句，過程返回，異常。原有的指針可能賦給另一個(gè)指針，你對(duì)這個(gè)指針也要做相同的事。
相比之下，對(duì)于一段用資源管理技術(shù)實(shí)現(xiàn)的代碼。你也用grep檢查所有的new，但是這次你只需要檢查鄰近的調(diào)用：
● 這是一個(gè)直接的Strong Pointer轉(zhuǎn)換，還是我們?cè)谝粋�(gè)構(gòu)造函數(shù)的函數(shù)體中？
● 調(diào)用的返回知是否立即保存到對(duì)象中，構(gòu)造函數(shù)中是否有可以產(chǎn)生異常的代碼。？
● 如果這樣的話析構(gòu)函數(shù)中時(shí)候有delete?
下一步，你需要用grep查找所有的release方法，并實(shí)施相同的檢查。
不同點(diǎn)是需要檢查、理解單個(gè)執(zhí)行路徑和只需要做一些本地的檢驗(yàn)。這難道不是提醒你非結(jié)構(gòu)化的和結(jié)構(gòu)化的程序設(shè)計(jì)的不同嗎？原理上，你可以認(rèn)為你可以應(yīng)付goto，并且跟蹤所有的可能分支。另一方面，你可以將你的懷疑本地化為一段代碼。本地化在兩種情況下都是關(guān)鍵所在。
在資源管理中的錯(cuò)誤模式也比較容易調(diào)試。最常見的bug是試圖訪問一個(gè)釋放過的strong pointer。這將導(dǎo)致一個(gè)錯(cuò)誤，并且很容易跟蹤。
1.2.9 共享的所有權(quán)
為每一個(gè)程序中的資源都找出或者指定一個(gè)所有者是一件很容易的事情嗎？答案是出乎意料的，是！如果你發(fā)現(xiàn)了一些問題，這可能說明你的設(shè)計(jì)上存在問題。還有另一種情況就是共享所有權(quán)是最好的甚至是唯一的選擇。
共享的責(zé)任分配給被共享的對(duì)象和它的客戶（client）。一個(gè)共享資源必須為它的所有者保持一個(gè)引用計(jì)數(shù)。另一方面，所有者再釋放資源的時(shí)候必須通報(bào)共享對(duì)象。最后一個(gè)釋放資源的需要在最后負(fù)責(zé)free的工作。
最簡(jiǎn)單的共享的實(shí)現(xiàn)是共享對(duì)象繼承引用計(jì)數(shù)的類RefCounted：
| class RefCounted { public: RefCounted () : _count (1) {} int GetRefCount () const { return _count; } void IncRefCount () { _count++; } int DecRefCount () { return --_count; } private int _count; }; |
按照資源管理，一個(gè)引用計(jì)數(shù)是一種資源。如果你遵守它，你需要釋放它。當(dāng)你意識(shí)到這一事實(shí)的時(shí)候，剩下的就變得簡(jiǎn)單了。簡(jiǎn)單的遵循規(guī)則--再構(gòu)造函數(shù)中獲得引用計(jì)數(shù)，在析構(gòu)函數(shù)中釋放。甚至有一個(gè)RefCounted的smart pointer等價(jià)物：
| template <class T> class RefPtr { public: RefPtr (T * p) : _p (p) {} RefPtr (RefPtr<T> & p) { _p = p._p; _p->IncRefCount (); } ~RefPtr () { if (_p->DecRefCount () == 0) delete _p; } private T * _p; }; |
注意模板中的T不比成為RefCounted的后代，但是它必須有IncRefCount和DecRefCount的方法。當(dāng)然，一個(gè)便于使用的RefPtr需要有一個(gè)重載的指針訪問操作符。在RefPtr中加入轉(zhuǎn)換語(yǔ)義學(xué)（transfer semantics）是讀者的工作。
1.2.10 所有權(quán)網(wǎng)絡(luò)
鏈表是資源管理分析中的一個(gè)很有意思的例子。如果你選擇表成為鏈(link)的所有者的話，你會(huì)陷入實(shí)現(xiàn)遞歸的所有權(quán)。每一個(gè)link都是它的繼承者的所有者，并且，相應(yīng)的，余下的鏈表的所有者。下面是用smart pointer實(shí)現(xiàn)的一個(gè)表單元：
| class Link { // ... private auto_ptr<Link> _next; }; 最好的方法是，將連接控制封裝到一個(gè)弄構(gòu)進(jìn)行資源轉(zhuǎn)換的類中。 對(duì)于雙鏈表呢？安全的做法是指明一個(gè)方向，如forward: class DoubleLink { // ... private DoubleLink *_prev; auto_ptr<DoubleLink> _next; }; |
注意不要?jiǎng)?chuàng)建環(huán)形鏈表。
這給我們帶來(lái)了另外一個(gè)有趣的問題--資源管理可以處理環(huán)形的所有權(quán)嗎？它可以，用一個(gè)mark-and-sweep的算法。這里是實(shí)現(xiàn)這種方法的一個(gè)例子：
| template<class T> class CyclPtr { public: CyclPtr (T * p) :_p (p), _isBeingDeleted (false) {} ~CyclPtr () { _isBeingDeleted = true; if (!_p->IsBeingDeleted ()) delete _p; } void Set (T * p) { _p = p; } bool IsBeingDeleted () const { return _isBeingDeleted; } private T * _p; bool _isBeingDeleted; }; |
注意我們需要用class T來(lái)實(shí)現(xiàn)方法IsBeingDeleted，就像從CyclPtr繼承。對(duì)特殊的所有權(quán)網(wǎng)絡(luò)普通化是十分直接的。
將原有代碼轉(zhuǎn)換為資源管理代碼
如果你是一個(gè)經(jīng)驗(yàn)豐富的程序員，你一定會(huì)知道找資源的bug是一件浪費(fèi)時(shí)間的痛苦的經(jīng)歷。我不必說服你和你的團(tuán)隊(duì)花費(fèi)一點(diǎn)時(shí)間來(lái)熟悉資源管理是十分值得的。你可以立即開始用這個(gè)方法，無(wú)論你是在開始一個(gè)新項(xiàng)目或者是在一個(gè)項(xiàng)目的中期。轉(zhuǎn)換不必立即全部完成。下面是步驟。
（1） 首先，在你的工程中建立基本的Strong Pointer。然后通過查找代碼中的new來(lái)開始封裝裸指針。
（2） 最先封裝的是在過程中定義的臨時(shí)指針。簡(jiǎn)單的將它們替換為auto_ptr并且刪除相應(yīng)的delete。如果一個(gè)指針在過程中沒有被刪除而是被返回，用auto_ptr替換并在返回前調(diào)用release方法。在你做第二次傳遞的時(shí)候，你需要處理對(duì)release的調(diào)用。注意，即使是在這點(diǎn)，你的代碼也可能更加"精力充沛"--你會(huì)移出代碼中潛在的資源泄漏問題。
（3） 下面是指向資源的裸指針。確保它們被獨(dú)立的封裝到auto_ptr中，或者在構(gòu)造函數(shù)中分配在析構(gòu)函數(shù)中釋放。如果你有傳遞所有權(quán)的行為的話，需要調(diào)用release方法。如果你有容器所有對(duì)象，用Strong Pointers重新實(shí)現(xiàn)它們。
（4） 接下來(lái)，找到所有對(duì)release的方法調(diào)用并且盡力清除所有，如果一個(gè)release調(diào)用返回一個(gè)指針，將它修改傳值返回一個(gè)auto_ptr。
（5） 重復(fù)著一過程，直到最后所有new和release的調(diào)用都在構(gòu)造函數(shù)或者資源轉(zhuǎn)換的時(shí)候發(fā)生。這樣，你在你的代碼中處理了資源泄漏的問題。對(duì)其他資源進(jìn)行相似的操作。
（6） 你會(huì)發(fā)現(xiàn)資源管理清除了許多錯(cuò)誤和異常處理帶來(lái)的復(fù)雜性。不僅僅你的代碼會(huì)變得精力充沛，它也會(huì)變得簡(jiǎn)單并容易維護(hù)。
本文導(dǎo)航
- 第1頁(yè): 首頁(yè)
- 第2頁(yè): 內(nèi)存泄漏
- 第3頁(yè): 探討C++內(nèi)存回收
- 第4頁(yè): 淺議C++ 中的垃圾回收方法
喜歡 
頂
難過
囧
圍觀
無(wú)聊