Effective C++笔记03：资源管理

资源：动态分配的内存、文件描写叙述器、相互排斥锁、图形界面中的字型与笔刷、数据库连接以及网络sockets等，不管哪一种资源，重要的是，当你不再使用它时，必须将它还给系统。

当我们向系统申请资源后，一定要记得释放，不然就easy发生内存泄漏。可是意识到这样一件事并非非常easy，比方我们是通过一个函数来动态分配内存并返回一个指针。

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。

在实际管理资源时，并不是全部的资源都是堆内存（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实现原理。

非常多API接口往往要求訪问原始资源，所以每个RAII class应该提供一个“取得其所管理之资源”的办法，比方提供一个get函数。

对原始资源的訪问可能经由显式转换或隐式转换。一般而言显式转换比較安全，但隐式转换对客户比較方便。

假设你在new表达式中使用[]，必须在对应的delete表达式中使用[]。假设你在new表达式中不使用[],一定不要在对应的delete表达式中使用[]。

string* stringPtr1 = new string;
string* stringPtr2 = new string[100];
delete stringPtr1;        // 删除一个对象
delete[] stringPtr2;    // 删除一个由对象组成的数组

如果我们有个函数用来控制程序的优先权，还有一个函数用来在某个动态分配所得到的Wieget上进行某些带有优先权的处理：

int priority();
void processWidget(shared_ptr<Widget>pw, int priority);

如今假如我们这样调用它：

processWidget(share_ptr<Widget>(new Widget),priotrity());

在调用processWidget之前，编译器必须创建代码，做下面三件事：

C++编译器并不保证上次代码运行的次序，但有一点能够保证，那就是new Widget肯定发生成share_ptr构造函数之前。

假如priority发生在第二步，而且运行过程中发生了异常，那就有可能资源不能正常的释放。

避免这样的情况，就须要使用分离语句，先创建Widget，然后再将它置入一个智能指针内，然后再把那个智能指针传给processWidget。

posted @ 2014-06-10 20:42 hrhguanli 阅读(240) 评论(0) 编辑收藏举报

刷新页面返回顶部

hrhguanli