第3章    资源管理

Resource Management

所谓资源就是,一旦用了它,将来必须还给系统.C++程序中最常使用的资源就是动态内存分配(如果分配内存从来都增归还,会导致内存泄露).其他常见的资源还有文件描述符(file descriptors),互斥锁(mutex locks),图形界面中的字型和笔刷,数据库连接,以及网络sockets.不论哪一种资源,重要的是,不再使用它时,必须将它还给系统.

条款13:    以对象管理资源

Use objects to manage resources.

假设使用一个用来塑模投资行为的程序库,其中各式各样的投资类型继承自一个root class Investment:

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

进一步假设,这个程序库通过一个工厂函数供应某特性的Investment对象:

Investment* createInvestment();    // 返回指针,指向动态分配对象

createInvestment的调用端使用了函数返回的对象后,有责任删除它.现在考虑有个f函数履行了这个责任:

void f() {

Investment* pInv = createInvestment();    // 调用factory函数

...

delete pInv;                            // 释放pInv所指对象

};

这看起来很妥当,但在若干情况下f可能无法删除它得自createInvestment的投资对象:

可能是因为"..."区域内的一个过早的 return 语句.如果这样一个 return 被执行起来,控制流就绝不会触及 delete 语句.

类似情况发生在对createInvestment的使用以及 delete 动作位于某循环内,而该循环由于某个 continue 或 goto 语句过早退出.

最后一个可能是"..."区域内的语句抛出异常,如果这样控制流将不会触及 delete.

无论 delete 如何被略过,泄露不只是内含投资对象的那块内存,还包括哪些投资对象所保存的任何资源.

谨慎地编写程序可以防止这一类错误,但是代码可能会在时间渐渐过去后背修改.一旦软件开始接受维护,可能会有某些人添加 return 语句或 continue 语句而未能全然领悟它对函数的资源管理策略造成的后果.更糟的是f的"..."区域有可能调用一个"过去从未抛出异常,却在被‘改善‘之后开始那么做"的函数.因此单纯依赖"f总是会执行其delete语句"是行不通的.

为确保createInvestment返回的资源总是被释放,需要将资源放进对象内,当控制流离开f,该对象的析构函数会自动释放那些资源.实际上这正是隐身于本条款背后的半边想法:把资源放进对象内,便可依赖C++的"析构函数自动调用机制"确保资源被释放.

许多资源被动态分配于heap内而后被用于单一区块或函数内.它们应该在控制流离开那个区块或函数时被释放.标准程序库提供的auto_ptr正是针对这种形势而设计的特质产品.auto_ptr是个"类指针对象",也就是所谓"智能指针",其析构函数自动对其所指对象调用 delete.下面示例如何使用auto_ptr以避免f函数潜在的资源泄露可能性:

void f() {

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

// 调用factory函数,一如既往地使用pInv,经由auto_ptr的析构函数自动删除pInv

...

}

这个简单的例子示范"以对象管理资源"的两个关键想法:

1.获得资源后立刻放进管理对象内.以上代码中createInvestment返回的资源被当作其管理者auto_ptr的初值.实际上"以对象管理资源"的观念常被称为"资源取得时机便是初始化时机"(Resource Acquisition Is Initialization;RAII).因为几乎总是在获得一笔资源后于同一语句内以它初始化某个管理对象.有时候获得的资源被拿来赋值(而非初始化)某个管理对象.但不论哪一种做法,每一笔资源都在获得的同时立刻被放进管理对象中.

2.管理对象运用析构函数确保资源被释放.不论控制流如何立刻区块,一旦对象被销毁(例如当对象立刻作用域)其析构函数自然会被自动调用,于是资源被释放.

由于auto_ptr被销毁时自动删除它所指的对象,所以一定要注意不能让多个auto_ptr同时指向同一对象.如果真是那样,对象会被删除一次以上,而且那会使程序出现"未定义行为".为了预防这个问题,auto_ptrs有一个不寻常的性质:若通过copy构造函数或copy assignment操作符复制它们,它们会变成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_ptr.

auto_ptr的替代方案是"引用计数型智慧指针"(reference-counting smart pointing;RCSP).所谓RCSP也是个智能指针,持续追踪共有多少对象指向某笔资源,并在无人指向它时自动删除该资源.RCSP提供的行为类似垃圾回收(garbage collection),不同的是RCSP无法打破环状引用(cycles of reference,例如两个其实已经没被使用的对象彼此互指,因而好像还处于"被使用"状态).

TR1的tr1::shared_ptr(见条款54)就是个RCSP,所以可以这么写f:

void f() {

...

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

// 调用factory函数,使用pInv,经由shared_ptr析构函数自动删除pInv

}

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

void f() {

...

std::tr1::shared_ptr<Investment> pInv1(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两者都在其析构函数内做 delete 而不是 delete[]动作(详见条款16).那意味着在动态分配而得的array上使用auto_ptr或tr1::shared_ptr是个坏主意.

std::auto_ptr<std::string> aps(new std::string[10]);    // 坏主意

std::tr1::shared_ptr<int> spi(new int[1024]);            // 坏主意

可以发现并没有特别针对"C++动态分配数组"而设计的类似auto_ptr或tr1::shared_ptr那样的东西,那是因为vector和string几乎总是可以取代动态分配而得的数组.

此外,必须指出createInvestment返回的是"未加工指针"(raw pointer)简直是对资源泄露的一个死亡邀约,因为使用者易在这个指针上忘记调用 delete.(即使使用auto_ptr或tr1::shared_ptr来执行 delete,首先必须记得将createInvestment的返回值存储于智能指针对象内).为与此问题搏斗,首先需要对createInvestment进行接口修改,那是条款18的事情.

注意:

版权声明：本文为博主原创文章，未经博主允许不得转载。