Effective C++——条款14(第3章)

条款14:    在资源管理类中小心copying行为

Think carefully about copying behavior in resource-managing classes
 
    条款13导入这样的观念:"资源取得时机便是初始化时机"(Resource Acquisition Is Initializaiton,RAII),并以此作为"资源管理类"的脊柱,也描述了auto_ptr和tr1::shared_ptr如何将这个观念表现在heap-based资源上.然而 并非所有资源都是heap-based,对那种资源而言,像auto_ptr和tr1::shared_ptr这样的智能指针往往不适合作为资源掌管者.既然如此, 偶尔还是需要建立自己的资源管理类.
    例如,假设使用C API函数处理类型为Mutex的互斥器对象,共有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;                // 定义需要的互斥器
...
{                              // 建立一个区块用来定义critical section
    Lock m1(&m);  // 锁定互斥器
    ...                        // 执行critical section内的操作
}                             // 在区块最末尾,自动解除互斥器锁定

    这很好,但如果Lock对象被赋值,会发生什么事?

Lock ml1(&m);                // 锁定m
Lock ml2(ml1);                // 将ml1复制到ml2上,这会发生什么事?

    这是某个一般化问题的特定例子. "当一个RAII对象被复制,会发生什么事情?",大多数时候会选择以下两种可能:
     1.禁止复制.许多时候允许RAII对象被复制并不合理.对一个像Lock这样的 class 是有可能的,因为很少能够合理拥有"同步化基础器物"(synchronization primitives)的副本.如果复制动作对RAII class 并不合理,则应该禁止.条款6告诉怎么做:将copying操作声明为 private.对Lock而言看起来是这样的:

class Lock : private Uncopyable {    // 禁止复制,详见条款6
public:
    ...
}; 

    2.对底层资源祭出"引用计数法"(reference-count).有时候希望保有资源,直到它的最后一个使用者被销毁.这种情况下复制RAII对象时,应该将资源的"被引用数"递增.tr1::shared_ptr便是如此.
    通常只要内含一个tr1::shared_ptr成员变量,RAII class 便可实现出reference-counting copying行为.如果前述的Lock打算使用reference counting.它可以改变mutexPtr的类型,将它从Mutex*改为tr1::shared_ptr<Mutex>.然而 很不幸tr1::shared_ptr的缺省行为是"当引用次数为0时删除其所指物",那不是想要的行为.当用上一个Mutext时,想要做的释放动作是解除锁定而非删除.
    幸运的是tr1::shared_ptr允许指定所谓的"删除器材(deleter)",那是一个函数或函数对象,当引用计数为0时便被调用(此机能并不存在于auto_ptr——它总是将其指针删除).删除器对tr1::shared_ptr构造函数而言是可有可无的第二参数,所以代码看起来像这样:

class Lock {
public:
    explicit Lock(Mutex* pm)    // 以某个Mutex初始化shared_ptr
        : mutexPtr(pm, unlock)    // 并以unlock函数为删除器
    {
        lock(mutexPtr.get());        // 条款15谈到"get"
    }
private:                                       // 使用shared_ptr替换raw pointer
    std::tr1::shared_ptr<Mutex> mutexPtr;
};                       

    本例中的Lock class 不再声明析构函数,因为没有必要.条款5说过,class 析构函数(不论是编译器生成的,或用户自定义的)会自动调用其non-static 成员变量(本例为mutexPtr)的析构函数.而mutexptr的析构函数会在互斥器的引用次数为0时自动调用tr1::shared_ptr的删除器(本例为unlock).
    复制底层资源.有时候,只要愿意,可以针对一份资源拥有其任意数量的副本.而需要"资源管理类"的唯一理由是,当不再需要某个副本时确保它被释放.在此情况下复制资源管理对象,应该同时也复制其所包裹的资源.也就是说,复制资源管理对象时,进行的是"深度拷贝".
    某些标准字符串类型是由"指向heap内存"的指针构成(那内存被用来存放字符串的组成字符).这种字符串对象内含一个指针指向一块heap内存.当这样一个字符串对象被复制,不论指针或其所指内存都会被制作出一个副本.这样的字符串展现深度复制(deep copying)行为.
    转移底部资源的拥有权.某些场合下可能希望确保永远只有一个RAII对象指向一个未加工资源(raw resource),即使RAII对象被复制依然如此.此时资源的拥有权会从被复制物转移到目标物.一如条款13所,这是auto_ptr奉行的复制意义.
    copying函数(包括copy构造函数和copy assignment操作符)有可能被编译器自动创建出来,因此除非编译器所生版本做了想要做的事,否则得自己编写它们.
     注意:
    复制RAII对象必须一并复制它所管理的资源,所以资源的copying行为决定RAII对象的copying行为.
    普遍而常见的RAII class copying行为是:抑制copying,施行引用计数法.