资源:动态分配的内存、文件描述器、互斥锁、图形界面中的字型与笔刷、数据库连接以及网络sockets等,无论哪一种资源,重要的是,当你不再使用它时,必须将它还给系统。
条款13:以对象管理资源
当我们向系统申请资源后,一定要记得释放,不然就容易发生内存泄漏。但是意识到这样一件事并不是很容易,比如我们是通过一个函数来动态分配内存并返回一个指针。
Investment* ceateInvestment();// 返回指针,指向动态分配对象
void f()
{
Investment* pInv = ceateInvestment();
// ...
delete pInv;
}
即使像上面的代码一样,我们在用完指针pInv后,我们调用了delete,但是还是可能出问题,有时候我们可能在...的部分提前return或跳出了循环,甚至在该部分发生了异常,这都导致delete根本执行不到。
解决方法是我们把指针放在一个资源管理的类里,让类对象在生命结束的时候,会自动调用析构函数,而析构函数里会执行delete。
两个常被使用的RAII类分别是:shared_ptr和unique_ptr,它们间不同的是shared_ptr允许存在同一内存区域的多个指针拷贝,而unique_ptr只允许一份指针指向对象,当uniuqe_ptr发生赋值操作时,用于赋值的指针将会变成null。
条款14:在资源管理类中小心copying行为
在实际管理资源时,并非所有的资源都是堆内存(heap),所以unique_ptr或shared_ptr这样的智能指针往往不适合作为资源管理者。
比如你需要控制类型为Mtux的互斥器对象,共有lock和unlock两函数可用,你需要保证的就是不要忘记将一个被锁住的Mutex解锁,我们的想法的主旨就是:资源在构造期间创建,在析构期间释放。
class Lock
{
public:
explicit Lock(Mutex* pm) :mutexPtr(pm){ lock(mutexPtr;) }// 获得资源
~Lock(){ unlock(mutexPtr); }// 释放资源
};
这样虽然很好,但是如果Lock被复制了,就会发生问题。它可能会引起对了一Mutex解锁两次。
常见的解决方案有2种:一种是禁止复制;第二种是对底层资源祭出“引用计数法”,这也是shared_ptr实现原理。
条款15:在资源管理类中提供对原始资源的访问
很多API接口往往要求访问原始资源,所以每一个RAII class应该提供一个“取得其所管理之资源”的办法,比如提供一个get函数。
对原始资源的访问可能经由显式转换或隐式转换。一般而言显式转换比较安全,但隐式转换对客户比较方便。
条款16:成对使用new和delete时要采用相同形式
如果你在new表达式中使用[],必须在相应的delete表达式中使用[]。如果你在new表达式中不使用[],一定不要在相应的delete表达式中使用[]。
string* stringPtr1 = new string;
string* stringPtr2 = new string[100];
delete stringPtr1; // 删除一个对象
delete[] stringPtr2; // 删除一个由对象组成的数组
条款17:以独立语句将newed对象置入智能指针
假设我们有个函数用来控制程序的优先权,另一个函数用来在某个动态分配所得到的Wieget上进行某些带有优先权的处理:
int priority();
void processWidget(shared_ptr<Widget>pw, int priority);
现在假如我们这样调用它:
processWidget(share_ptr<Widget>(new Widget),priotrity());
在调用processWidget之前,编译器必须创建代码,做以下三件事:
- 调用priority
- 执行”new Widget”
- 调用shared_ptr构造函数
C++编译器并不保证上次代码执行的次序,但有一点可以保证,那就是new Widget肯定发生成share_ptr构造函数之前。
假如priority发生在第二步,并且执行过程中发生了异常,那就有可能资源不能正常的释放。
避免这种情况,就需要使用分离语句,先创建Widget,然后再将它置入一个智能指针内,然后再把那个智能指针传给processWidget。
Effective C++:资源管理,布布扣,bubuko.com