C++条款：以对象管理资源 4/55

以对象管理资源

Use objects to manage resources

假设我们使用一个用来塑模投资行为（股票、债券等等）的程序库，其中各式各样的投资类型继承自一个root class Investment：

class Investment{...}

这个程序库通过一个工厂函数(factory function)供应我们某特定的Investment对象：

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

一如以上注释所言，createInvestment的调用端使用了函数返回的对象后，有责任删除之。

void f()
{
    Investment* pInv = createInvestment();
    ...
    delete pInv;
}

看起来妥当，但若干情况下f可能无法删除它得自createInvestment的投资对象——因为“...”区域内的一个过早的return语句、亦或是类似情况发生在对createInvestment的使用及delete动作位于某循环内，而该循环由于某个continue或goto语句过早退出、最后一种可能是"..."区域内的语句抛出异常，果真如此控制流将再次不会幸临delete。我们泄露的不只是内含投资对象的那块内存，还包括那些投资对象所保存的任何资源。

为确保createInvestment返回的资源总是被释放，我们需要将资源放进对象内，当控制流离开f，该对象的析构函数户自动释放那些资源。实际上这正是隐身于本条款背后的半边想法：把资源放进对象内，我们便可以倚赖C++的 “析构函数自动调用机制”确保资源被释放。

标准程序库提供的auto_ptr正是针对这种情况而设计的特制产品。

auto_prt是个“类指针(pointer-like)对象”，其析构函数自动对其所指对象调用delete。

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

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

• 获得资源后立刻放进管理对象(managing object)内

       以上代码中createInvestment返回的资源被当做其管理者auto_ptr的初值

• 管理对象(managing object)运用析构函数确保资源被释放。

由于auto_ptr被销毁时会自动删除它所指之物，所以一定要注意别让多个auto_ptr同时指向同一对象。如果真是那样，对象会被删除一次以上，而那会使你的程序搭上驶向“未定义行为”的快速列车。

为了预防这个问题，auto_ptr有个不寻常的性质：若通过copy各构造函数copy assignment操作符复制它们，它们会变成Null，而复制所得的指针将取得资源的唯一拥有权！

std::auto_ptr<Investment>
 pInv(createInvestment());                //pInv1指向
                                          //createInvestment返回物
std::auto_ptr<Investment> pInv2(pInv1);   //现在pInv2指向对象，
                                          //现在pInv1被设为null
pInv1 = pInv2;                            //现在pInv1指向对象，pInv2被设为Null

这一诡异的复制行为，加上其底层条件：“受auto_ptr管理的资源必须绝对没有一个以上的auto_ptr同时指向它”，意味auto_ptr并非管理动态分配资源的神兵利器。举个例子，STL容器要求其元素发挥“正常的”复制行为，因此这些容器容不得auto_ptr.

 

auto_ptr的替代方案是“引用计数型智慧指针”(reference-counting smart pointer,RCSP)

所谓RCSP也是个智能指针，持续追踪共有多少对象指向某笔资源，并在无人指向它时自动删除该资源。RCSP提高的行为类似垃圾回收（garbage collection），不同的是RCSPs无法打破环状引用（cycles of references）。

例如假设现在已经有这么个指针TR1的tr1::shared_ptr就是个RCSP（实现日后定会讨论，先研究怎么使用），所以你可以这么写：

void f()
{
    ...
    std::tr1::shared_ptr<Investment>
    pInv(createInvestment());
    ...
}

这段代码看起来几乎和使用auto_ptr的那个版本相同，但tr1::shared_ptr的复制行为正常多了：

void f()
{
    ...
    std::tr1::shared_ptr<Investment>
    pInv(createInvestment());        //pInv1 指向
                                     //createInvestment返回物
    std::tr1::shared_ptr<Investment>
    pInv2(pInv1);                    //pInv1和pInv2指向同一个对象
    pInv1 = pInv2;
    ...
}                                    //pInv1和pInv2被销毁
                                     //它们所指的对象也就被自动销毁

由于tr1::shared_ptr的复制行为“一如预期”，它们可被用于STL容易以及其他“auto_ptr”的非正统复制行为并不适用”

当然，本条款并不专门针对auto_ptr,tr1::shared_ptr或任何其他智能指针，而是强调“以对象管理资源”的重要性。

需要注意的是，auto_ptr和tr1::shared_ptr两者都在其析构函数内做delete而不是delete[]动作。那意味在动态分配而得的array身上使用auto_ptr或tr1::shared_ptr是个馊主意。尽管如此，那样做仍能通过编译。

而对于“C++动态分配数组”，并没有类似上述那样的智能指针，但日后会讨论到Boost，它们会提供我们想要的行为。

另外需指出，createInvestment返回的“未加工指针”是造成资源泄露的一个隐患，因为调用者极易在这个指针身上忘记调用delete，即使它们使用了智能指针来执行delete，它们首先必须记得将createInvestment的返回值存储于智能指针内。为与此问题搏斗，首先需要对createInvestment接口进行修改，那也是日后讨论的事。

总结：

• 为防止资源泄露，请使用RAII对象，它们在构造函数中获得资源并在析构函数中释放资源
• 两个常被使用的RAII classes分别是tr1::shared_ptr和auto_ptr。前者通常是较佳选择，因为其copy行为比较直观。若选择auto_ptr，复制动作使它指向null

编于03/26/2019 16:24