借来的资源，如何还的潇洒？

• 获得资源后立刻放进管理对象内。以上代码中 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 是数组大小：

当你对着一个指针使用 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 过) 对象存储于智能指针内。如果不这样做，一旦异常被抛出，有可能导致难以察觉的资源泄漏。