条款14:在资源管理类中小心coping行为(Think carefully about copying behavior in resource-managing classes.)

条款14:在资源管理类中小心coping行为(Think carefully about copying behavior in resource-managing classes.)

对不是heap-based那种资源而言，像auto_ptr和trl::shared_ptr这样的智能指针往往不适合作为资源掌管者(resource handlers )。既然如此，有可能偶而你会发现，你需要建立自己的资源管理类。

1. Lock类

为确保绝不会忘记将一个被锁住的Mutex解锁

//C API

void lock(Mutex* pm); //锁定pm所指的互斥器. 

void unlock(Mutex* pm); //将互斥器解除锁定.

//Lock类

class Lock

{

public:

    explicit Lock(Mutex* pm)

      :mutexPtr(pm)

    {lock(mutexPtr);}//获得资源

    ~Lock() { unlock(mutexPtr); } //释放资源

private:

    Mutex *mutexPtr;

};

//调用代码

Mutex m;             //定义你需要的互斥器

{                           //建立一个区块用来定义critical section.

    Lock ml(&m); //锁定互斥器.

                             //执行critical section内的操作.

}//在区块最末尾，自动解除互斥器锁定.

//有问题的调用方式（RAII对象复制问题）

Lock mll(&m); //锁定m

Lock ml2(mll); //将mll复制到m12身上。这会发生什么事? 

 

2. 资源管理类coping行为

1）禁止复制

private继承Uncopyable

2）对底层资源祭出“引用计数法”（reference-count）

class Lock{

public:

    explicit Lock(Mutex* pm) //以某个Mutex初始化shared_ptr

      :mutexPtr(pm, unlock)//并以unlock函数为删除器.

        {

          lock(mutexPtr.get());//条款15谈到”get"

        }

private:

    std::trl::shared_ptr<Mutex> mutexPtr;//使用shared_ptr

};//替换~pointer

trl::shared_ptr的缺省行为是‘当引用次数为0时删除其所指物”，那不是我们所要的行为。当我们用上一个Mutex，我们想要做的释放动作是解除锁定而非删除。trl::shared_ttr允许指定所谓的“删除器”( deleter )一个函数或函数对象(function object)，当引用次数为0时便被调用。

3）复制底部资源

深度复制(deep copyipg )：字符串对象内含一个指针指向一块heap内存。当这样一个字符串对象被复制，不论指针或其所指内存都会被制作出一个复件。

4）转移底部资源的拥有权

资源的拥有权会从被复制物转移到目标物。auto_ptr的复制意义。

 

3. 结论

1）复制RAII对象必须一并复制它所管理的资源，所以资源的copying行为决定RAII对象的copying行为。

2）普遍而常见的RAII class copying行为是：抑制copying、施行引用计数法(reference counting )。不过其他行为也都可能被实现。