条款13 以对象管理资源

总结：

1. 为了防止资源泄漏，使用 RAII 对象，在 RAII 对象的构造函数中获得资源并在析构函数中释放它们。

2.  两个通用的 RAII 是 tr1::shared_ptr 和 auto_ptr。前者通常是更好的选择，因为其拷贝行为比较直观。若选择 auto_ptr，复制动作会使被复制物指向null。

假设我们使用一个用来塑模投资行为（例如股票、债券等）的程序库，各种各样的投资类型继承自root class Investment。进一步假设这个库使用了通过一个 factory 函数为我们提供特定 Investment 对象的方法：

class Investment { ... }; // “投资类型”继承体系中的root class

Investment* createInvestment(); /*返回指向Investment继承体系内的动态分配对象的指针。调用者有责任删除它。这里为了简化，刻意不写参数*/

当 createInvestment 函数返回的对象不再使用时，由调用者负责删除它。下面的函数 f 来履行以下职责：

void f()
{
Investment *pInv = createInvestment(); // 调用factory对象
... 
delete pInv; // 释放pInv所指对象
}

以下几种情形会造成 f 可能无法删除它得自 createInvestment 的投资对象：

1.     "..." 部分的某处有一个提前出现的 return 语句，控制流就无法到达 delete 语句；

2.     对 createInvestment 的使用和删除在一个循环里，而这个循环以一个 continue 或 goto 语句提前退出；

3.     "..." 中的一些语句可能抛出一个异常，控制流不会再到达那个 delete。

单纯依赖“f总是会执行其delete语句”是行不通的。

为了确保 createInvestment 返回的资源总能被释放，我们需要将资源放入对象中，当控制流离开f，这个对象的析构函数会自动释放那些资源。将资源放到对象内部，我们可以依赖 C++ 的“析构函数自动调用机制”确保资源被释放。

许多资源都是动态分配到堆上的，并在单一区块或函数内使用，且应该在控制流离开那个块或函数的时候释放。标准库的 auto_ptr 正是为这种情形而设计的。auto_ptr 是一个类似指针的对象（智能指针），它的析构函数自动对其所指对象调用 delete。下面就是如何使用 auto_ptr 来预防 f 的潜在的资源泄漏：

void f()
{
std::auto_ptr<Investment> pInv(createInvestment()); // 调用工厂函数
... // 一如以往地使用pInv
} // 经由auto_ptr的析构函数自动删除pInv

这个简单的例子示范了“以对象管理资源”的两个关键想法：

·    获得资源后应该立即放进管理对象内。如上，createInvestment 返回的资源被用来初始化即将用来管理它的 auto_ptr。实际上“以对象管理资源”的观念常被称为“资源取得时机便是初始化时机” （Resource Acquisition Is Initialization ；RAII)，因为我们几乎总是在获得一笔资源后于同一语句内以它初始化某个管理对象。有时被获取的资源是被赋值给资源管理对象的（而不是初始化），但这两种方法都是在获取资源的同时就立即将它移交给资源管理对象。

·    管理对象使用它们的析构函数确保资源被释放。因为当一个对象被销毁时（例如，当一个对象离开其活动范围）会自动调用析构函数，无论控制流程是怎样离开一个块的，资源都会被正确释放。如果释放资源的动作会引起异常抛出，事情就会变得棘手。

当一个 auto_ptr 被销毁的时候，会自动删除它所指向的东西，所以不要让超过一个的 auto_ptr 指向同一个对象。如果发生了这种事情，那个对象就会被删除超过一次，而且会让你的程序进入不明确行为。为了防止这个问题，auto_ptrs 具有不同寻常的特性：拷贝它们（通过拷贝构造函数或者拷贝赋值运算符）就会将它们置为null，而复制所得的指针将取得资源的唯一拥有权！

std::auto_ptr<Investment>pInv1(createInvestment());

// pInv1指向createInvestment 返回物

std::auto_ptr<Investment> pInv2(pInv1);

// 现在pInv2指向对象，pInv1被设为 null

pInv1 = pInv2; // 现在pInv1指向对象，pInv2被设为null

受auto_ptrs 管理的资源必须绝对没有超过一个以上的 auto_ptr 同时指向它，这也就意味着 auto_ptrs 不是管理所有动态分配资源的最好方法。例如，STL 容器要求其元素发挥正常的复制行为，因此这些容器容不得auto_ptrs。

auto_ptrs的替代方案是引用计数型智能指针（reference-counting smart pointer, RCSP）。RCSP能持续跟踪有多少对象指向一个特定的资源，并能够在不再有任何东西指向那个资源的时候删除它。就这一点而论，RCSP 提供的行为类似于垃圾收集（garbage collection）。不同的是， RCSP 不能打破循环引用（例如，两个没有其它使用者的对象互相指向对方）。TR1 的tr1::shared_ptr就是个 RCSP：

void f()
{
...

    std::tr1::shared_ptr<Investment> pInv(createInvestment());

    // 调用factory 函数
... // 使用pInv一如既往
} // 经由shared_ptr析构函数自动删除pInv

这里的代码看上去和使用 auto_ptr 的几乎相同，但是拷贝 shared_ptrs 的行为却自然得多：

void f()
{
...

    std::tr1::shared_ptr<Investment>pInv1(createInvestment());

    // pInv指向createInvestment对象

    std::tr1::shared_ptr<Investment>pInv2(pInv1);

    //pInv1和pInv2指向同一个对象

    pInv1= pInv2; // 同上，无任何改变
...
} // pInv1和pInv2被销毁，它们所指的对象也就被自动销毁

因为拷贝 tr1::shared_ptrs 的行为“符合预期”，它们能被用于 STL 容器以及其它和 auto_ptr 的非正统的拷贝行为不相容的环境中。auto_ptr 和 tr1::shared_ptr 都在它们的析构函数中使用 delete，而不是 delete []。这就意味着将 auto_ptr 或 tr1::shared_ptr 用于动态分配的数组是个馊主意。

C++ 中没有可用于动态分配数组的类似 auto_ptr 或 tr1::shared_ptr 这样的东西，甚至在 TR1 中也没有。那是因为 vector 和 string 几乎总是能代替动态分配数组。你也可以去看看 Boost，boost::scoped_array 和 boost::shared_array 两个类提供了你在寻找的行为。

如果你手动释放资源（例如，使用 delete，而不使用资源管理类），你就是在自找麻烦。像 auto_ptr 和 tr1::shared_ptr 这样的预制的资源管理类通常会使本条款的建议变得容易，但有时你所使用的资源是目前这些预制的类无法妥善管理的，你就需要精心打造自己的资源管理类。最后必须指出 createInvestment 返回的“未加工指针”（raw pointer）是资源泄漏的请帖，因为调用者极易忘记在他们取回来的指针上调用 delete。（即使他们使用一个 auto_ptr 或 tr1::shared_ptr 来完成 delete，他们仍然必须记住将 createInvestment 的返回值存储到智能指针对象中）。