条款14：在资源管理类中小心copying行为——96

并非所有资源都是以堆为基础，对那种资源而言，像auto_ptr和shared_ptr这样的智能指针往往不适合作为资源掌管着。既然如此，有可能偶尔你会发现，你需要建立自己的资源管理类。
我们使用C API函数处理类型为Mutex的互斥器对象，共有lock和unlock两函数可用：

void lock(Mutex* pm);   //锁定pm所指的互斥器
void unlock(Mutex* pm); //将互斥器解除锁定

为确保绝不会忘记将一个被锁住的Mutex解锁，你可能会希望建立一个class用来管理机锁：

class Lock{
public:
    explicit Lock(Mutex*  pm):mutexPtr(pm){ lock(mutexPtr); }
    ~Lock(){ unlock(mutexPtr); }
private:
    Mutex *mutexPtr;
};

如果出现Lock对象被复制，会发生什么事:

Mutex m;
...
Lock ml1(&m);
Lock ml2(ml1);

大多数时你会选择以下几种可能：
（1）禁止复制。如果复制动作对RAII class并不合理，你变应该禁止。条款6：将copying操作声明为private。对Lock而言看起来是这样：

class Lock:private Uncopyable{
public:
    ...
};

（2）对底层资源利用“引用计数法”。因为对于Mutex，我们想要做的施放动作是解除锁定而非删除，因此使用shred_ptr不是很合理。
但幸运的是shared_ptr允许指定所谓“删除器”，那是一个函数或函数对象，当引用次数为0时便被调用。删除器对shared_ptr构造函数而言是可有可无的第二参数，所以代码可能是这样：

class Lock{
public:
    explicit Lock(Mutex* pm):mutexPtr(pm,unlock) //以unlock函数为删除器
    {
        lock(mutexPtr.get());
    }
private:
    std::tr1::shared_ptr<Mutex> mutexPtr;
};

请注意，本例的Lock class不再声明析构函数。因为没有必要。
（3）复制底部资源。你可以针对一份资源拥有其任意数量的复件。而你需要“资源管理类”的唯一理由是，当你不再需要某个复件时确保它被释放。在此情况下复制资源管理对象，应该同时也复制其所包覆的资源。也就是说，复制资源管理对象时，进行的是“深度拷贝”。
（4）转移底部资源的拥有权。某些罕见场合下你可能希望确保永远只有一个RAII对象指向一个未加工资源，即使RAII对象被复制依然如此。此时资源的拥有权会从被复制物转移到目标物。

总结——99

（1）复制RAII对象必须一并复制它所管理的资源，所以资源的copying行为决定RAII对象的coping行为。
（2）普遍而常见的RAII class copying行为是：抑制copying、施行引用计数法。不过其他行为也都可能被实现。