我们定一个投资行为的程序库,其中各式各样的投资类型继承自一个root类Investment:
class Investment( ... );
这个程序库系通过一个工厂函数供应我们某特定的Investment对象:
Investment* createinvestment();
createInvestment的调用返回指针,指向Investment继承体系内的动态分配对象。调用者有责任删除它。现在考虑有个f函数履行了这个责任:
void f(){
Investment* pInv=createInvestment();
...
delete pInv;
}
这看起来妥当,但若干情况下f可能无法删除它得自createInvestment的投资对象——或许因为“…”区域内的一个过早的return语句,或许发生在createInvestment的使用及delete动作位于某循环内,而该循环由于某个continue或goto语句过早退出,再或许可能是“…”区域内的语句抛出异常。无论delete如何被略过去,我们泄漏的不只是内含投资对象的那块内存,还包括那些投资对象所保存的任何资源。
不管情况如何,单纯依赖“f总是会执行其delete语句”是行不通的。
为确保createInvestment返回的资源总是被释放,我们需要将资源放进对象内,当控制流离开f,该对象的析构函数会自动释放那些资源。
RAII守则
资源取得时机便是初始化时机(Resource Acquisition Is Initialization;RAII)。
利用auto_prt(已弃用)以避免f函数潜在的资源泄漏可能性——93
void f(){
std::auto_ptr<Investment> pInv(creasteInvestment());
...
}
这个例子示范“以对象管理资源”的两个关键想法:
(1)获得资源后立刻放进管理对象内。
(2)管理对象运用析构函数确保资源被释放。
由于auto_ptr被销毁时会自动删除它所指之物,所以一定要注意别让多个auto_ptr同时指向同一对象。如果真是那样,对象会被删除一次以上。
auto_ptr不能支持复制行为——94
我们来看:
std::auto_ptr<Investment> pInvl(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。
使用shared_ptr自动释放资源——94
auto_ptr的替代方案是“引用计数型智慧指针”(reference-counting smart pointer;RCSP),
f函数可写成:
void f(){
...
std::tr1::shared_pt<Investment> pInv(createInvestment());
...
}
shared_ptr的复制行为比auto_ptr正常:
void f(){
...
std::tr1::shared_ptr<Investment> pInv1(createInvestment()); //pInv1指向createInvestment返回物
std::tr1::shared_ptr<Investment> pInv2(pInv1); //pInv1和pInv2指向同一个对象
pInv1=pInv2;
...
}
由于tr1::share_ptr的复制行为“一如预期”,它们可被用于STL容器以及其他“auto_ptr的非正统复制行为并使用“的语境上。
总结——96
(1)为防止资源泄漏,请使用RAII对象,它们在构造函数中获得资源并在析构函数中释放资源。
(2)两个常被使用的RAII classes分别是tr1::shared_ptr和auto_ptr。前者通常是较佳选择,因为其copy行为比较直观。若选择auto_ptr,复制动作会使它(被复制物)指向null。