在资源管理类中心小心coping行为——条款14

        条款13导入这样的概念：“资源取得时机便是初始化时机”（Resource Acquisition Is Initialization;RAII），并以此作为“资源管理类”的脊柱，也描述了auto_ptr和tr1::shared_ptr如何将这个观念表现在heap-based资源上。然而并非所有资源都是heap-based，对那种资源而言，像auto_ptr和tr1::shared_ptr这样的智能指针往往不适合作为资源掌管者。既然如此，有可能偶尔你会发现，你需要建立自己的资源管理类。

        例如，假设我们使用C API函数处理类型为Mutex的互斥器对象（mutex objects），共有lock和unlock两函数可用：

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

为确保绝不会忘记将一个被锁住的Mutex解锁，你可能会希望建立一个class用来管理。这样的class的基本结构由RAII守则支配，也就是“资源在构造期间获得，在析构期间释放”：

class Lock {
public:
    explicit Lock(Mutex* pm)
    : mutexPtr(pm)
    { lock(mutexPtr); }         // 获得资源
    ~Lock() { unlock(mutexPtr); }   // 释放资源
private:
    Mutex *mutexPtr;
};

       客户对Lock的用法符合RAII方式：

Mutex m;  // 定义需要的互斥器
...
{
    Lock ml(&m);    // 锁定互斥器
    ...             // 执行相关操作
}                   // 区块最末尾，自动解除互斥器锁定

        当一个RAII对象被复制，会发生什么事？

Lock m11(&m);     // 锁定m
Lock m12(&m11);   // 将m11复制到m12身上。这会发生什么事？

        大多数时候你会选择一下两种可能：

• 禁止复制。许多时候允许RAII对象被复制并不合理。具体禁止方法参考条款6.
• 对底层资源祭出“引用计数法”。有时候我们希望保有资源，直到它的最后一个使用者（某对象）被销毁。这种情况下复制RAII对象时，应该将资源的“被引用数”递增。tr1::shared_ptr便是如此。

        通常只要内含一个tr1::shared_ptr成员变量，RAII classes便可实现出reference-counting copying行为。如果前述Lock打算使用references counting，它可以改变mutexPtr的类型，将它从Mutex*改为tr1::shared_ptr<Mutex>。然而很不幸tr1::shared_ptr的缺省行为是“当引用次数为0时删除其所指物”，那不是我们所要的行为。当我们用上一个Mutex，我们想要做的释放动作是解除锁定而非删除。

        幸运的是tr1::shared_ptr提供了“删除器”（deleter），可以是一个函数或函数对象，当引用次数为0时便被调用（此机能并不存于auto_ptr——它总是将其指针删除）。删除器对tr1::shared_ptr构造函数而言是可有可无的第二参数，所以代码看起来像这样：

class Lock {
public:
    explicit Lock(Mutex* pm)
    : mutexPtr(pm, unlock)        // unlock函数为删除器
    { 
        lock(mutexPtr.get());     // 条款15谈到“get”
    }         
private:
    std::trl::shared_ptr<Mutex> mutexPtr;
};

        请注意，本例的Lock class不在声明析构函数。因为没有必要。条款5说过，class析构函数（无论编译器生成，或用户自定）会调用其non-static成员变量（本例为mutexPtr）的析构函数。而mutexPtr的析构函数会在互斥器的引用次数为0时自动调std::trl::shared_ptr的删除器（本例为unlock）。

• 复制底部资源。有时候，只要你喜欢，可以针对一份资源拥有其任意数量的副本。而你需要“资源管理类”的唯一理由是，当你不再需要某个副本时确保它被释放。在此情况下复制资源管理对象，应该同时也复制其所包覆的资源。也就是说，复制资源管理对象时，进行的是“深度拷贝”。
• 转移底部资源的拥有权。某些罕见场合下你可能希望确保永远只有一个RAII对象指向一个未加工资源，即使RAII对象被复制依然如此。此时资源的拥有权会从被复制物转移到目标物。一如条款13所述，这是auto_ptr奉行的复制意义。

        Coping函数（包括copy构造函数和copy assignment操作符）有可能被编译器自动创建出来，因此除非编译器所生版本做了你想要做的事（条款5提过其缺省行为），否则你得自己编写它们。某些情况下或许也想支持这些函数的一般版本，这样的版本描述于条款45.

请记住

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

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