Effective C++(14) 在资源管理类中小心copying行为

问题聚焦:
    上一条款所告诉我们的智能指针,只适合与在堆中的资源,而并非所有资源都是在堆中的。
    这时候,我们可能需要建立自己的资源管理类,那么建立自己的资源管理类时,需要注意什么呢?。

在详述这一章的主题之前,先回忆一下上一节所提到的一个名词—— RAII(Resource Acquisition Is Initialization)
含义就是:资源取得时机便是初始化时机。
如果上一节对这个观念的理解还不是很深的话,那么下面这个例子可以让你更好地理解。

Demo 假设我们使用C API函数处理类型为Mutex的互斥器对象,共有lock和unlock两函数可用。
void lock(Mutex* pm);
void unlock(Mutex* pm);

为了确保不会忘记将一个被锁住的Mutex解锁,你可能会希望简历一个class用来管理锁。
这样的class的基本结构由RAII守则支配,也就是在“资源构造期间获得,在析构期间释放”
class Lock {
public:
    explicit Lock(Mutex* pm) : mutexPtr(pm)
    { lock(mutexPtr);    }     // 获得资源
    ~Lock() 
    { unlock(mutexPtr); }    // 释放资源
};

// 客户对Lock的正确用法符合RAII方式
Mutex m;         // 定义你需要的互斥器
....
{                         // 建立一个区块用来定义critical section
    Lock ml(&m);      // 锁定互斥器
    ......
}                        // 在区块最末尾,自动接触互斥器锁定

上面的用法自然没有什么问题,那么问题是什么呢?——如果Lock对象被复制,会发生什么事呢?就像下面这样:
Lock ml1(&m);
Lock ml2(ml1);


一般化这个问题就是:当一个RAII对象被复制时, 会发生什么事情呢?

大多数情况下,有两种解决方法:
1 禁止复制:复制动作对RAII class并不合理。如果阻止复制操作,可以转到: Effective C++(6) 如何拒绝编译器的自动生成函数
2 对底层资源祭出“引用计数法:
    通常,只要内含一个tr::shared_ptr成员变量,就可以实现引用技术。代码是下面这个样子的:
    class Lock {
    public:
        explicit Lock(Mutex* pm) : mutexPtr(pm, unlock)  
        {
            lock(mutexPtr.get());
        }
    private:
        std::tr1LLshared_ptr mutexPtr;
    };

需要注意的一点是:tr1::shared_ptr的缺省行为是“当引用次数为0时,删除其所指对象”,或许这并不是我们想要的行为。幸运的是,tr1::shared_ptr并不是只能删除对象,而是允许指定我们想要的动作,只需要在第二个参数上传递一个对象或函数对象,当引用次数为0时,便被调用。
在本例中,传递的就是解锁函数,而不是删除所指对象。

遇到RAII的复制动作时,我们还可以有别的处理方式:
1 复制底部资源
    复制资源管理对象时,同时也可以复制其所包含的资源,因此进行的应该是“深拷贝”。
    例如:当一个对象包含一个指针指向一块堆内存时,复制这个对象,同时其指针和指向的内存都会被复制出一个复件。
2 转移底部资源的拥有权
    在某些场合下,你可能希望确保永远只有一个RAII对象指向一个未加工的资源,就像auto_ptr的复制行为。详见:   Effective C++(13) 用对象管理资源

小结:
  • 复制RAII对象必须一并复制它所管理的资源,所以资源的拷贝行为决定RAII对象的拷贝行为
  • 一般的复制行为是:阻止拷贝行为,使用引用计数法(tr1::shared_ptr)

参考资料:
《Effective C++ 3rd》


你可能感兴趣的:(C/C++)