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