• 獲得資源后立刻放進管理對象內。以上代碼中 createA 返回的資源被當做其管理者 auto_ptr 的初值，也就立刻被放進了管理對象中。
• 管理對象運用析構函數確保資源釋放。不論控制流如何離開區塊，一旦對象被銷毀(例如當對象離開作用域)其析構函數自然會被自動調用，于是資源被釋放。

為什么在 C++11 建議棄用 auto_ptr 嗎?當然是 auto_ptr 存在缺陷，所以后續不被建議使用。

auto_ptr 有一個不尋常的特質：若通過「復制構造函數或賦值操作符函數」 copy 它們，它們會變成 null ，而復制所得的指針將獲取資源的唯一擁有權!

見如下例子說明：

意味著 auto_ptr 并非管理動態分配資源的神兵利器。

std::unique_ptr

unique_ptr 也采用所有權模型，但是在使用時，是直接禁止通過復制構造函數或賦值操作符函數 copy 指針對象，如下例子在編譯時，會出錯：

shared_ptr 在使用復制構造函數或賦值操作符函數后，引用計數會累加并且兩個指針對象指向的都是同一個塊內存，這就與 unique_ptr、auto_ptr 不同之處。

由于 shared_ptr 釋放空間時會事先要判斷引用計數值的大小，因此不會出現多次刪除一個對象的錯誤。

小結 - 請記住

• 為防止資源泄漏，請使用 RAII(Resource Acquisition Is Initaliaztion - 資源取得時機便是初始化時機) 對象，它們在構造函數中獲取資源，并在析構函數中是釋放資源
• 兩個建議使用的 RAII classes 分別是 std::unique_ptr 和 std::shared_ptr。前者不允許 copy 動作，后者允許 copy 動作。但是不建議用 std::auto_ptr，若選 auto_ptr，復制動作會使它(被復制物)指向 null 。

細節 02：在資源管理類中小心 copying 行為

假設，我們使用 C 語音的 API 函數處理類型為 Mutex 的互斥對象，共有 lock 和 unlock 兩函數可用：

void locak(Mutex *pm);  // 鎖定 pm 所指的互斥器 
void unlock(Mutex* pm); // 將互斥器解除鎖定 

為確保絕不會忘記一個被鎖住的 Mutex 解鎖，我們可能會希望創立一個 class 來管理鎖資源。這樣的 class 要遵守 RAII 守則，也就是「資源在構造期間獲得，在析構釋放期間釋放」：

class Lock 
{ 
public: 
    explicit Lock(Mutex *pm) // 構造函數 
        : pMutex(pm) 
    { 
        lock(pMutex); 
    } 
 
    ~Lock()  // 析構函數 
    { 
        unlock(pMutex); 
    } 
private: 
    Mutex* pMutex; 
}; 

這樣定義的 Lock，用法符合 RAII 方式：

Mutex m;      //定義你需要的互斥鎖 
...  
{                 // 建立一個局部區塊作用域 
    Lock m1(&m);  // 鎖定互斥器 
    ... 
}                 // 在離開區塊作用域，自動解除互斥器鎖定 

這很好，但如果 Lock 對象被復制，會發生什么事情?

Lock m1(&m);  // 鎖定m 
Lock m2(&m1); // 將 m1 復制到 m2身上，這會發生什么？ 

這是我們需要思考和面對的：「當一個 RAII 對象被復制，會發生什么事情?」大多數時候你會選擇以下兩種可能：

• 禁止復制。如果 RAII 不允許被復制，那我們需要將 class 的復制構造函數和賦值操作符函數聲明在 private。
• 使用引用計數法。有時候我們希望保有資源，直到它的最后一個對象被消耗。這種情況下復制 RAII 對象時，應該將資源的「被引用數」遞增。std::shared_ptr 便是如此。

如果前述的 Lock 打算使用使用引用計數法，它可以使用 std::shared_ptr 來管理 pMutex 指針，然后很不幸 std::shared_ptr 的默認行為是「當引用次數為 0 時刪除其所指物」那不是我們想要的行為，因為要對Mutex釋放動作是解鎖而非刪除。

幸運的是 std::shared_ptr 允許指定自定義的刪除方式，那是一個函數或函數對象。如下：

class Lock 
{ 
public: 
    explicit Lock(Mutex *pm)   
        : pMutex(pm, unlock)  // 以某個 Mutex 初始化 shared_ptr， 
                              // 并以 unlock 函數為刪除器。 
    { 
        lock(pMutex.get());  // get 獲取指針地址 
    } 
 
private: 
    std::shared_ptr<Mutex> pMutex; // 使用 shared_ptr 
}; 

請注意，本例的 Lock class 不再聲明析構函數。因為編譯器會自動創立默認的析構函數，來自動調用其 non-static 成員變量(本例為 pMutex )的析構函數。

而 pMutex 的析構函數會在互斥器的引用次數為 0 時，自動調用 std::shared_ptr 的刪除器(本例為 unlock )。

小結 - 請記住

• 復制 RAII 對象必須一并復制它的所管理的資源(深拷貝)，所以資源的 copying 行為決定 RAII 對象的 copying 行為。
• 普通而常見的 RAII class copying 行為是：禁止 copying、執行引用計數法。

細節 03 ：在資源類中提供對原始資源的訪問

智能指針「顯式」轉換，也就是通過 get 成員函數的方式轉換為原始指針對象。

上面提到的「智能指針」分別是：std::auto_ptr、std::unique_ptr、std::shared_ptr。它們都有訪問原始資源的辦法，都提供了一個 get 成員函數，用來執行顯式轉換，也就是它會返回智能指針內部的原始指針(的復件)。

舉個例子，使用智能指針如 std::shared_ptr 保存 createA() 返回的指針對象 ：

int getInfo(const A* pA); 

你想這么調用它：

智能指針都重載了指針取值操作符(operator->和operator*)，它們允許隱式轉換至底部原始指針：

所以對于自身設計 RAII classes 我們也要提供一個「取得其所管理的資源」的辦法。

小結 - 請記住

• APIs 往往要求訪問原始資源，所以每一個 RAII class 應該提供一個「取得其所管理的資源」的辦法。
• 對原始資源的訪問可能經由顯式轉換或隱式轉換。一般而言顯式轉換比較安全，但隱式轉換比較方便。

細節 04：成對使用 new 和 delete以下動作有什么錯?

std::string* strArray = new std::string[100]; 
... 
delete strArray; 

每件事情看起來都井然有序。使用了 new，也搭配了對應的 delete。但還是有某樣東西完全錯誤。strArray 所含的 100 個 string 對象中的 99 個不太可能被適當刪除，因為它們的析構函數很可能沒有被調用。

當使用 new ，有兩件事發生：

• 內存被分配出來(通過名為 operator new 的函數)
• 針對此內存會有一個或多個構造函數被調用

當使用 delete，也會有兩件事情：

• 針對此內存會有一個或多個析構函數被調用
• 然后內存才被釋放(通過名為 operator delete 的函數)

delete 的最大問題在于：即將被刪除的內存之內究竟有多少對象?這個答案決定了需要執行多少個析構函數。

對象數組所用的內存通常還包括「數組大小」的記錄，以便 delete 知道需要調用多少次析構函數。單一對象的內存則沒有這筆記錄。你可以把兩者不同的內存布局想象如下，其中 n 是數組大?。?/p>

當你對著一個指針使用 delete，唯一能夠讓 delete 知道內存中是否存在一個「數組大小記錄」的辦法就是：由你告訴它。如果你使用 delete 時加上中括號[]，delete 便認定指針指向一個數組，否則它便認定指針指向一個單一對象：

std::string* strArray = new std::string[100]; 
std::string* strPtr = new std::strin; 
...  
delete [] strArray;  // 刪除一個對象 
delete strPtr;       // 刪除一個由對象組成的數組 

游戲規則很簡單：

如果你在 new 表達式中使用[]，必須在相應的 delete 表達式也使用[]。

如果你在 new 表達式中不使用[]，一定不要在相應的 delete 表達式使用[]。

小結 - 請記住

• 如果你在 new 表達式中使用[]，必須在相應的 delete 表達式也使用[]。如果你在 new 表達式中不使用[]，一定不要在相應的 delete 表達式使用[]。

細節 05：以獨立語句將 newed 對象置入智能指針

假設我們有個以下示范的函數：

fun(new A(), getNum()); 

它不能通過編譯，因為 std::shared_ptr 構造函數需要一個原始指針，而且該構造函數是個 explicit 構造函數，無法進行隱式轉換。如果寫成這樣就可以編譯通過：

于是在調用 fun 函數之前，先必須做以下三件事：

• 調用 getNum 函數
• 執行 new A 表達式
• 調用 std::shared_ptr 構造函數

那么他們的執行次序是一定如上述那樣的嗎?可以確定的是 new A 一定比std::shared_ptr 構造函數先被執行。但對 getNum 調用可以排在第一或第二或第三執行。

如果編譯器選擇以第二順位執行它：

1. 執行 new A 表達式
2. 調用 getNum 函數
3. 調用 std::shared_ptr 構造函數

萬一在調用 getNum 函數發生了異常，會發生什么事情?在此情況下 new A 返回的指針將不會置入 std::shared_ptr 智能指針里，就存在內存泄漏的現象。

避免這類問題的辦法很簡單：使用分離語句。

分別寫出：

1. 創建 A
2. 將它置入一個智能指針內
3. 然后再把智能指針傳遞給 fun 函數。

小結 - 請記住

• 以獨立語句將 newed (已 new 過) 對象存儲于智能指針內。如果不這樣做，一旦異常被拋出，有可能導致難以察覺的資源泄漏。