【翻译】[Effective C++第三版•中文版][第14条]要留心资源管理类中的复制行为

[转]http://www.cppblog.com/tiandejian/archive/2007/05/11/ec_14.html

第14条：     要留心资源管理类中的复制行为

第 13 条 中介绍了“资源获取即初始化”（ Resource Acquisition Is Initialization ，简称 RAII ）的概念，它是资源管理的主要内容。同时第 13 条 中 还使用 auto_ptr 和 tr1::shared_ptr 作为示例，描述了这一概念是如何管理堆上的资源的。然而并不是所有的资源都分配于堆上，对于不分配于堆上的资源，类似于 auto_ptr 和 tr1::shared_ptr 这一类的智能指针并不适合于处理它们。这是千真万确的，你必须不时地自己动手，创建自己的资源管理类。

举例说，你正使用一个 C 语言的 API 所提供 的 lock 和 unlock 函 数 来处理 Mutex 类型的互斥对象：

void lock(Mutex *pm);              // 通过 pm 为互斥量上锁

void unlock(Mutex *pm);            // 为互斥量解锁

为了确保你曾上锁的互斥量都得到解锁，你应该自己编写一个类来管理互斥锁。这样的类的基本结构应遵 循 RAII 的 原理，那就是：资源在构造过程中获得，在析构过程中释放：

class Lock {

public:

 explicit Lock(Mutex *pm)

 : mutexPtr(pm)

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

 

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

 

private:

 Mutex *mutexPtr;

};

客户端程序员通过传统 的 RAII 风 格来使用 Lock 类：

Mutex m;                           // 定义互斥量以便使用

...

{                                  // 创建程序块用来定义临界区

 Lock ml(&m);                      // 为互斥量上锁

...                                // 进行临界区操作

}                                  // 在程序块末尾互斥量将自动解锁

这样可以正常工作，但是如果复制一个 Lock 对象，将会发生些什么呢？

Lock ml1(&m);                      // 为 m 上锁

 

Lock ml2(ml1);                      // 把 ml1 复制给 ml2

                                   // 将会发生什么呢？

有一个问题是所有 的 RAII 类创建者必须面对的，那就是：当复制一个 RAII 对象时需要做些什么呢？以上是对于这个一般化问题的一个较具体的示例。大多数时候，以下四种可行的方案供你选择。

l 禁止复制。 在许多情况下，允许 RAII 被复制没有任何意义。比如对于 Lock 类来说就是这样，因为复制同步原型在大多数情况下都没有什么意义。当复制一个 RAII 类无意义时，你就应该禁止它。第 6 条中详细介绍了实现方法：将拷贝赋值运算符声明为私有的。对于 Lock 而言，应该是下面的情形：

class Lock: private Uncopyable {       // 防止复制 — 参见第 6 条

public:

 ...                                   // 同上

};

l 为基础资源进行引用计数。 有时，我们期望能保留对一个资源的所有权，直到其所涉及的最后一个对象被删除为止。在这种情况下，复制一个 RAII 对象将会添加一个引用资源对象的计数。这就是 tr1::shared_ptr 所使用的“复制”的含义。

通常情况下， RAII 类可以通过包含一个 tr1::shared_ptr 数据成员来实现引用计数复制行为。举例说，如果 Lock 曾希望使用引用计数，它可能会将 mutexPtr 的类型从 Mutex* 更改为 tr1::shared_ptr<Mutex> 。但是不幸的是， tr1::shared_ptr 默认的行为是：当引用计数值变为零时，删除其所指向的内容，但这不是我们想要的。当一个 Mutex 用完时，我们希望对其进行的操作是解锁，而不是删除它。

所幸的是， tr1::shared_ptr 允许定义一个“删除器”，它是一个函数或一个函数对象，在引用计数值为零时，它将得到调用。（ auto_ptr 并不包含这一特性，它总是删除它所指向的内容。）删除器可作为 tr1::shared_ptr 构造函数的另一个可选参数，所以代码应该是这样的：

class Lock {

public:

 explicit Lock(Mutex *pm)     // 初始化 shared_ptr ，参数为

 : mutexPtr(pm, unlock)       // 所指向的互斥量和解锁函数

 

    lock(mutexPtr.get());       // 关于 "get" 的信息请参见第 15 条

 }

 

private:

 std::tr1::shared_ptr<Mutex> mutexPtr;

};                             // 使用 shared_ptr 而不是裸指针

在本示例中，请注意 Lock 类不再声明析构函数。这是因为我们不再需要它了。第 5 条中介绍了一个类的析构函数（无论是编译器自动生成的还是用户自定义的）会自动为类的非静态数据成员进行析构。本示例中 mutexPtr 就将被自动析构。 当互斥量的引用计数变为零时， 析构函数会析构 mutexPtr ，然而此时实际上 将会调用 tr1::shared_ptr 的删除器 unlock 。（通常你应该为这个类的代码添加一段注释，告诉人们你并没有忘记编写析构函数，而是把工作留给了编译器自动生成的默认析构函数。这样人们思路会更清晰一些。他们会感激你的。）

l 复制主要的资源。 一些时候，你可以在需要的情况下为资源复制出任意份数的副本，此时你需要一个资源管理类的唯一理由就是：确保每份副本在其工作完成之后得到释放。在这种情况下，复制资源管理对象的同时，也要复制出其涉及的资源。也可以说，复制一个资源管理对象时，将进行“深度复制”。

标准 string 类型的一些实现版本中，包含着一个指向堆内存的指针，这个指针所指向的就是字符串所保存的位置。这样的 string 对象包含着一个指向堆内存的指针。当一个 string 对象被复制完成之后，复制出的这一副本将由这一指针和其指向的内存共同组成。这样的 string 就进行了一次深度复制。

l 传递主要资源的所有权。 在少数情况下，你可能需要确保仅仅有一个 RAII 对象引用了一个未定义类型的资源，当复制这一 RAII 对象时，资源的所有权也从源对象传递到目标对象了。如同第 13 条中所解释的，这是通过 auto_ptr 所实现的“复制”的含义。

拷贝函数（拷贝构造函数和拷贝赋值运算符）可能由编译器自动生成，但是如果编译器自动生成版本无法满足你的需要（第 5 条中解释了 C++ 中的默认行为），你就应该自己编写这些汉书。在一些情况下，你可能还会需要这些函数的范型版本。这些版本将在第 45 条中介绍。

牢记在心

l 复制一个 RAII 对象的同时也要复制其所管理的对象，所以资源管理的复制行为由 RAII 对象的复制行为决定。

l 一般的 RAII 类在复制时应遵循两条原则：不允许使用复制，要进行资源计数。但也不要拘泥于这两个原则。