章节回顾:
《Effective C++》第1章 让自己习惯C++-读书笔记
《Effective C++》第2章 构造/析构/赋值运算(1)-读书笔记
《Effective C++》第2章 构造/析构/赋值运算(2)-读书笔记
《Effective C++》第3章 资源管理(1)-读书笔记
《Effective C++》第8章 定制new和delete-读书笔记
内存只是你必须管理的众多资源之一。其他常见的资源还包括文件描述器(file descriptors)、互斥锁(mutex locks)、图形界面中的字型和笔刷、以及网络sockets。无论哪一种资源,重要的是当你不再使用它时,将它还给系统。
条款13:以对象管理资源
下面有一个Investment继承体系:
class Investment { ... };
Investment是root class,获得Investment体系的对象是通过工厂函数:
Investment* createInvestment(); //返回指针指向Investment继承体系动态分配对象
显然,createInvestment的调用者使用后,有责任删除返回的指针,以释放对象。假设函数f()负责这个行为:
void f() { Investment *pInv = createInvestment(); ... delete pInv; }
但至少存在几种情况使得f()无法删除createInvestment对象:
(1)…区域有一个过早的return语句,导致delete没执行。
(2)…区域抛出异常,控制流不会转向delete。
当delete时,我们泄露的不只是内含Investment对象的那块内存,还包括其所保存的任何资源。
为确保createInvestment()返回的资源总是被释放,我们需要将资源放进对象内,当控制流离开f()时,该对象的析构函数会自动释放那些资源。标准库提供的auto_ptr是个“类指针对象”,即智能指针,其析构函数自动对其所指对象调用delete。
下面是f()的修正版:
void f() { std::auto_ptr<Investment> pInv(createInvestment()); //由auto_ptr的析构函数自动删除pInv ... }
f()说明了以对象管理资源的两个重要方面:
(1)获得资源后立刻放进管理对象内。
以资源管理对象的观念常被称为“资源取得时机便是初始化时机”(Resource Acquisition Is Initialization, RAII)。每一笔资源在获得的同时立刻被放进管理对象中。
(2)管理对象运用析构函数确保资源被释放。
无论控制流如何离开f(),一旦对象离开作用域(对象被销毁),其析构函数被调用,资源被释放。
注意:由于auto_ptr被销毁时会自动删除它所指之物,所以别让多个auto_ptr同时指向某一对象。为了预防这个问题auto_ptr有一个很好的性质:若通过copy构造函数或copy assignment操作符复制它们,它们会变成null,而复制所得的指针将取得资源的唯一权。
std::auto_ptr<Investment> pInv1(createInvestment()); std::auto_ptr<Investment> pInv2(pInv1); //pInv2指向对象,pInv1被设为null pInv1 = pInv2; //pInv1指向对象,pInv2被设为null
正是因为auto_ptr对象具备“非正常”的拷贝性质,所以不能用于STL容器的元素等。
auto_ptr的替代方案是:引用计数型智能指针(reference-counting smart pointer (RCSP))。RCSP能够追踪共有多少对象指向某种资源,并在无人指向它时自动删除该资源。RCSP提供的行为类似垃圾回收,不同的是它无法打破环状引用,例如,两个其实已经没被使用的对象彼此互指,好像对象还处于“被使用”状态。
TR1的tr1::shared_ptr就是一个RCSP,f()的新写法:
void f() { std::tr1::shared_ptr<Investment> pInv(createInvestment()); ... }
f()的新版本与使用auto_ptr几乎相同,但拷贝行为正常了:
void f() { ... std::tr1::shared_ptr<Investment> pInv1(createInvestment()); std::tr1::shared_ptr<Investment> pInv2(pInv1); //pInv1和pInv2指向同一对象 pInv1 = pInv2; //pInv1和pInv2指向同一对象 ... }
因为shared_ptr的复制行为是正常的,所以可用于STL容器以及其他auto_ptr非正常复制行为并不适用的情况。
特别注意:auto_ptr和shared_ptr两者都在析构函数内做delete而不是delete[]。所以下面的操作是非常错误的:
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总是可以取代动态数组,这是你的第一选择。
请记住:
(1)为防止资源泄露,请使用RAII对象,它们在构造函数中获得资源并在析构函数中释放资源。
(2)两个常被使用的RAII class分别是:tr1::shared_ptr和auto_ptr。前者是最好的选择,因为其copy行为比较正常。auto_ptr的copy会使被复制物指向null。
条款14:在资源管理类中小心copying行为
并非所有资源都是heap-based的,对这种资源auto_ptr和tr1::shared_ptr这样的智能指针往往不适用。举例如下:
有两个函数用来处理Mutex互斥器对象:
void lock(Mutex *pm); //锁定pm指向的互斥器 void unlock(Mutex *pm); //解锁
为确保不会忘记解锁,可以建立一个class管理锁,这个class基本结构由RAII支配,即“资源在构造期间获得,在析构期间释放”。
class Lock { public: explicit Lock(Mutex *pm) : mutexPtr(pm) { lock(mutexPtr); } ~Lock() { unlock(mutexPtr); } private: Mutex *mutexPtr; };
客户是这样使用的:
Mutex m; //定义所需的互斥器 { ... Lock ml(&m); //锁定互斥器 ... } //自动解锁
这样使用是可以的。但如果发生copy的情况呢?即当一个RAII对象被复制,会发生什么事情?
Lock ml1(&m); Lock ml2(ml1);
有四种可能:
(1)禁止复制。
许多时候允许RAII对象被复制并不合理。
(2)对底层资源使用“引用计数法”。
有时候我们希望保存资源,直到它的最后一个使用者被销毁。tr1::shared_ptr便是如此处理。
注意:tr1::shared_ptr的缺省行为是当引用次数为0时删除其所指物,我们想要的是释放锁,而不是删除。我们可以指定“删除器”,这是一个函数,当引用次数为0时会被调用。auto_ptr无此性质,它总是删除它的指针。
更改后的版本是:
class Lock { public: explicit Lock(Mutex *pm) : mutexPtr(pm, unlock) //unlock为删除器 { lock(mutexPtr.get()); } private: std::tr1::shared_ptr<Mutex> mutexPtr; //使用shared_ptr替换raw_pointer };
注意:这个lock class不需要析构函数了,因为编译器会自动调用mutexPtr的析构函数,当引用计数为0时,自动调用删除器。
(3)复制底部资源
可以针对一份资源拥有任意数量的副本。这是的复制是深拷贝。
(4)转移底部资源的拥有权
你可能希望永远只有一个RAII对象指向一个raw recource,即使RAII对象被复制。这是资源的拥有权会从被复制物转移到目标物。auto_ptr便是如此。
注意:copying函数(包括copy构造函数和copy assignment操作符)有可能被编译器创造出来,因此除非编译器版本做了你想做的事,否则你要自己编写它们。
请记住:
(1)复制RAII对象必须一并复制它所管理的资源,所以资源的copying行为决定RAII对象的copying行为。
(2)普遍常见的RAII class copying行为是:禁止copying、使用引用计数。其他行为也可能被实现。