条款13 : 以对象管理资源
假设有如下代码:
Investment* createInvestment(); //返回指针,指向Investment继承体系内的动态分配对象,调用者有责任删除它 void func() { Investment* pInv = createInvestment(); //调用factory函数 ..... delete pInv; //释放pInv所指对象 }
上述代码可能出现如下问题导致无法删除pInv指针所指对象,出现资源泄露。
(1)“.....”区域内一个过早结束的return语句;
(2)delete动作位于某个循环内,而该循环由于某个continue或goto语句过早结束;
(3)“.....”区域内语句抛出异常;
解决方案:把资源放进对象内,我们便可倚赖C++的“析构函数自动调用机制”确保资源被释放。标准程序库提供的auto_ptr正是针对这种形势而设计的特制产品。auto_ptr是个“类指针(pointer-like)对象”,也就是所谓“智能指针”,其析构函数自动对其所指对象调用delete。如下:
void func() { std::auto_ptr<Investment> pInv (createInvestment()); ..... // 调用factory函数,经由auto_ptr的析构函数自动删除pInv }
解析:
1. 获得资源后立刻放进管理对象内。实际上,“以对象管理资源”的观念常被称为“资源取得时机便是初始化时机”(Resource Acquisition Is Initialization;RAII)。每一笔资源都在获得的同时立刻被放进管理对象中。
2. 管理对象运用析构函数确保资源被释放。即便析构抛出异常,条款08也已经给出解决方案。
这里简单介绍一下“智能指针”:
auto_ptr采用“所有权”方式管理对象,也即对于auto_ptr的赋值、复制操作将直接交割对象的所有权,所以一定注意不要让多个auto_ptr同时指向同一个对象。
auto_ptr的替代方案是“引用计数型智慧指针”(reference-counting smart pointer;RCSP),其也是一个智能指针,持续追踪共有多少对象指向某笔资源,并在无人指向它时自动删除该资源。TR1的tr1::shared_ptr(条款54)就是个RCSP。上述代码可修改如下:
void func() { ..... std::tr1::shared_ptr<Investment> pInv (createInvestment()); ..... // 调用factory函数,经由shared_ptr的析构函数自动删除pInv }
注:上述auto_ptr和tr1::shared_ptr只不过是“以对象管理资源”在本条款中所使用的例子。同时,createInvestment返回“未加工指针”(raw pointer)简直是对资源泄漏的一个死亡邀约,其一,调用者极易在这个指针身上忘记调用delete;其二,即使想使用智能指针,也有可能会忘记将createInvestment的返回值存储于智能对象内。所以,条款18提供了一个解决方法:令createInvestment返回一个智能指针。如:
std::tr1::shared_ptr<Investment> createInvestment() { std::tr1::shared_ptr<investment> retVal (static_case<Investment*>(0), getRidOfInvestment); // 第一个参数是指针,使用cast转型得到 retVal = ....; //令retVal指向正确对象 return retVal; }
这便强迫客户将返回值存储于一个tr1::shared_ptr内。
故而:
1. 为防止资源泄漏,请使用RAII对象,它们在构造函数中获得资源并在析构函数中释放资源。
2. 两个常被使用的RAII classes分别是auto_ptr和tr1::shared_ptr。后者通常是较佳选择,因为其copy行为比较直观。若选择auto_ptr,复制动作会使它(被复制物)指向Null。
条款14 : 在资源管理类中小心copying行为
条款13导入这样的观念:“资源取得时机便是初始化时机”(RAII),并以此作为“资源管理类”的脊柱,也描述了auto_ptr和tr1::shared_ptr如何将这个观念表现在heap-based(基于堆)资源上。然而,并非所有的资源都是heap-based,对那种资源而言,像auto_ptr和tr1::shared_ptr这样的智能指针往往不适合作为资源掌管者。偶尔,我们需要建立自己的资源管理类。考虑如下代码:
// Metex的互斥器对象,为确保绝不会忘记将一个被锁住的Mutex解锁,需要建立一个class管理机锁 class Lock { public: explicit Lock(Mutex* pm) :mutexPtr(pm) { lock(mutexPtr); } // 获得资源 ~Lock() { unlock(mutexPtr); } // 释放资源 private: Mutex *mutexPtr; }; // 客户对Lock的用法符合RAII方式 Mutex m; //定义你需要的互斥器 ..... { // 建立一个区块用来定义critical section. Lock ml(&m); // 锁定互斥器 ..... // 执行critical section内的操作 } //如果Lock对象被复制,会发生什么事? Lock ml1(&m); //锁定m Lock ml2(ml1); // 将ml1复制到ml2身上,这会发生什么事 ?
面对RAII对象被复制,可选择的解决方案:
1. 禁止复制。条款6已经说明如何禁止复制动作。(将copying函数声明为private)
2. 对底层资源祭出“引用计数法”。tr1::shared_ptr便是如此。可将mutexPtr类型从Mutex* 改为 tr1::shared_ptr<Mutex>.
注意:面对互斥器,当引用计数为0时,我们想要做的释放动作是解除锁定而非删除。幸运的是tr1::shared_ptr允许指定所谓的“删除器”,那是一个函数或函数对象,当引用计数为0时便被调用。如下:
class Lock { public: explicit Lock(Mutex* pm) // 以某个Mutex初始化shared_ptr :mutexPtr(pm, unlock) // 并以unlock函数为删除器 { lock(mutexPtr.get()); //条款15谈到“get" } private: std::tr1::shared_ptr<Mutex> mutexPtr; //使用shared_ptr替换raw pointer };
本例的Lock class不再声明析构函数。因为没有必要。条款05说过,class 析构函数会自动调用其non-static成员变量(本例为mutexPtr)的析构函数。而mutexPtr的析构函数会在互斥器的引用计数为0时自动调用tr1::shared_ptr的删除器(本例为unlock).
3. 复制底部资源。也就是说,复制资源管理对象是,进行的是”深度拷贝“。
4. 转移底部资源的拥有权。这是auto_ptr奉行的复制意义。
故而:
1. 复制RAII对象必须一并复制它所管理的资源,所以资源的copying行为决定RAII对象的copying行为。
2. 普遍而常见的RAII class copying行为是:抑制copying、施行引用计数法。不过其他行为也都可能被实现。
条款15 : 在资源管理类中提供对原始资源的访问
许多APIs直接指涉原始资源,所以提供对原始资源的访问有时很必要。
1. tr1::shared_ptr和auto_ptr都提供一个get成员函数,用来执行显式转换,也就是它会返回智能指针内部的原始指针(的复件):
2. 就像(几乎)所以智能指针一样,tr1::shared_ptr和auto_ptr也重载了指针取值操作符(operator-> 和 operator*),他们允许隐式转换至底部原始指针。
如:
class Investment { public: bool isTaxFree() const; .... }; Investment * createInvestment (); //factory函数 std::tr1::shared_ptr<Investment> pi1(createInvestment()); //令tr1::shared_ptr管理一笔资源 bool taxable1 = !(pi1->isTaxFree()); //经由operator->访问资源,pi1隐式转换至底部原始指针,调用原始指针成员函数 ........
3. 对于资源管理类,显式转换和隐式转换例子如下 :
FontHandle getFont(); void releaseFont(FontHandle fh); class Font { //RAII class public: explicit Font(FontHandle fh) // 获得资源 :f(fh) //采用pass-by-value,因为C API这样做。 { } ~Font() { releaseFont(f); } private: FontHandle f; //原始(raw)字体资源 }; //显式转换-------------------------------------------------------------- class Font { public: ...... FontHandle get() const { return f; } //显式转换函数 ...... }; // 客户调用 void changeFontSize(FontHandle f, int newSize); Font f(getFont()); int newFontSize; ..... changeFontSize(f.get(), newFontSize); //显式将Font转换为FontHandle //隐式转换-------------------------------------------------------------- class Font { public: ..... operator FontHandle() const // 隐式转换函数 { return f; } ...... }; //客户调用 Font f(getFont()); int newFontSize; ..... changeFontSize(f, newFontSize); //将Font隐式转换为FontHandle //但这个隐式转换会增加错误机会,例如,客户需要拷贝一个Font对象,如下 Font f1(getFont()); ..... FontHandle f2 = f1; //Font 错写成FontHandle,则不会报错,而是将f1隐式转换为其底部的FontHandle,然后才复制它。
这样结果就变成生成了一个FontHandle对象,而客户原意是要拷贝一个Font对象。
故而:
1. APIs往往要求访问原始资源,所以每一个RAII class应该提供一个“取得其所管理之资源”的办法。
2. 对原始资源的访问可能经由显式转换或隐式转换。一般而言显式转换(提供一个显式转换函数,如get)比较安全,但隐式转换(类中重写“()”运算符)对客户比较方便。
条款16 : 成对使用new和delete时要采取相同形式
请记住:
如果你在new表达式中使用[], 必须在相应的delete表达式中也使用[]。如果你在new表达式中不使用[],一定不要在相应的delete表达式中使用[]>
条款17 : 以独立语句将newed对象置入智能指针
因为在“资源被创建(经由“new”)”和“资源被转换为资源管理对象”两个时间点之间有可能发生异常干扰。考虑如下代码:
int priority(); void processWidget(std::tr1::shared_ptr<Widget> pw, int priotity); //考虑如下调用 processWidget(new Widget, priority()); //不能通过编译,因为tr1::shared_ptr构造函数需要一个原始指针,但该构造函数是个explicit构造函数,无法进行隐式转换 // 改成以下形式则可通过编译 processWidget(std::tr1::shared_ptr<Widget> (new Widget), priotity());
编译器产出一个processWidget调用码之前,必须首先核算即将被传递的各个实参。于是在调用processWidget之前,编译器必须创建代码,做以下三件事:
(1)调用priority
(2)执行“new Widget"
(3) 调用tr1::shared_ptr构造函数
至于C++编译器以什么次序完成上述三件事呢 ?这个不确定,唯一能保证的是“new Widget”一定先于tr1::shared_ptr构造函数。如果最终以如下顺序执行:
执行“new Widget” --> 调用priority --> 调用tr1::shared_ptr构造函数
现在假设,万一对priority的调用导致异常,那么“new Widget”返回的指针将会遗失,因为它尚未被置入tr1::shared_ptr内,而后者是我们期盼用来防卫资源泄漏的武器。所以,在对processWidget的调用过程中可能引发资源泄漏。因为在“资源被创建(经由“new”)”和“资源被转换为资源管理对象”两个时间点之间有可能发生异常干扰。
解决方案:
使用分离语句,分别写出(1)创建Widget,并将它置入一个智能指针内,(2)再把这个智能指针传给processWidget. 如下:
std::tr1::shared_ptr<Widget> pw (new Widget); //在单独语句以智能指针存储newed所得对象 processWidget(pw, priority); //这个调用动作绝不至于造成泄漏
以上之所以行得通,因为编译器对于“跨越语句的各项操作”没有重新排列的自由(只有在语句内它才拥有那个自由度(参数列表))。
故而:
以独立语句将newed对象存储于(置入)智能指针内。如果不这样做,一旦异常被抛出,有可能导致难以察觉的资源泄漏。