# Item 14: 谨慎考虑资源管理类的拷贝行为
作者：Scott Meyers
译者：fatalerror99 (iTePub's Nirvana)
发布：http://blog.csdn.net/fatalerror99/
Item 13 介绍了作为资源管理类支柱的 Resource Acquisition Is Initialization (RAII) 原则，并描述了 auto_ptr 和 tr1::shared_ptr 在基于堆的资源上运用这一原则的表现。然而，并非所有的资源都是基于堆的，对于这样的资源，像 auto_ptr 和 tr1::shared_ptr 这样的智能指针通常就不像 resource handlers（资源管理者）那样合适。在这种情况下，有时，你可能要根据你自己的需要去创建你自己的资源管理类。
例如，假设你使用 C API 提供的 lock 和 unlock 函数去操纵 Mutex 类型的互斥体对象：
```
void lock(Mutex *pm); // lock mutex pointed to by pm
void unlock(Mutex *pm); // unlock the mutex
```
为了确保你从不会忘记解锁一个被你加了锁的 Mutex，你希望创建一个类来管理锁。RAII 原则规定了这样一个类的基本结构，通过构造函数获取资源并通过析构函数释放它：
```
class Lock {
public:
explicit Lock(Mutex *pm)
: mutexPtr(pm)
{ lock(mutexPtr); } // acquire resource
~Lock() { unlock(mutexPtr); } // release resource
private:
Mutex *mutexPtr;
};
```
客户按照 RAII 风格的惯例来使用 Lock：
```
Mutex m; // define the mutex you need to use
...
{ // create block to define critical section
Lock ml(&m); // lock the mutex
... // perform critical section operations
} // automatically unlock mutex at end
// of block
```
这没什么问题，但是如果一个 Lock 对象被拷贝应该发生什么？
```
Lock ml1(&m); // lock m
Lock ml2(ml1); // copy ml1 to ml2—what should
// happen here?
```
这是一个更一般问题的特定实例，每一个 RAII 类的作者都要面临这样的问题：当一个 RAII 对象被拷贝的时候应该发生什么？大多数情况下，你可以从下面各种可能性中挑选一个：
* 禁止拷贝。在很多情况下，允许 RAII 被拷贝是没有意义的。这对于像 Lock 这样类很可能是正确的，因为同步的基本要素的“副本”很少有什么意义。当拷贝对一个 RAII 类没有什么意义的时候，你应该禁止它。Item 6 解释了如何做到这一点。声明拷贝操作为私有。对于 Lock，看起来也许像这样：
```
class Lock: private Uncopyable { // prohibit copying — see
public: // Item 6
... // as before
};
```
* 对底层的资源引用计数。有时人们需要的是保持一个资源直到最后一个使用它的对象被销毁。在这种情况下，拷贝一个 RAII 对象应该增加引用这一资源的对象的数目。这也就是使用 tr1::shared_ptr 时“拷贝”的含意。
通常，RAII 类只需要包含一个 tr1::shared_ptr 数据成员就能够实现引用计数的拷贝行为。例如，如果 Lock 要使用引用计数，他可能要将 mutexPtr 的类型从 Mutex\* 改变为 tr1::shared_ptr<Mutex>。不幸的是，tr1::shared_ptr 的缺省行为是当它所指向的东西的引用计数变为 0 的时候将它删除，但这不是我们要的。当我们使用 Mutex 完毕后，我们想要将它解锁，而不是将它删除。
幸运的是，tr1::shared_ptr 允许一个 "deleter" 规范——当引用计数变为 0 时调用的一个函数或者函数对象。（这一功能是 auto_ptr 所没有的，auto_ptr 总是删除它的指针。）deleter 是 tr1::shared_ptr 的构造函数的可选的第二个参数，所以，代码看起来就像这样：
```
class Lock {
public:
explicit Lock(Mutex *pm) // init shared_ptr with the Mutex
: mutexPtr(pm, unlock) // to point to and the unlock func
{ // as the deleter
lock(mutexPtr.get()); // see Item 15 for info on "get"
}
private:
std::tr1::shared_ptr<Mutex> mutexPtr; // use shared_ptr
};
```
在这个例子中，注意 Lock 类是如何不再声明一个析构函数的。那是因为它不再需要。Item 5 解释了一个类的析构函数（无论它是编译器生成还是用户定义）会自动调用这个类的非静态（non-static）数据成员的析构函数。在本例中，就是 mutexPtr。但是，当互斥体的引用计数变为 0 时，mutexPtr 的析构函数会自动调用的是 tr1::shared_ptr 的 deleter ——在此就是 unlock。（看过这个类的源代码的人多半意识到需要增加一条注释表明你并非忘记了析构，而只是依赖编译器生成的缺省行为。）
* 拷贝底层的资源。有时就像你所希望的你可以拥有一个资源的多个副本，唯一的前提是你需要一个资源管理类确保当你使用完它之后，每一副本都会被释放。在这种情况下，拷贝一个资源管理对象也要同时拷贝被它隐藏的资源。也就是说，拷贝一个资源管理类需要完成一次“深层拷贝”。
某些标准 string 类型的实现是由堆内存的指针组成，堆内存中存储着组成那个 string 的字符。这样的字符串对象包含指向堆内存的指针。当一个 string 对象被拷贝，这个副本应该由那个指针和它所指向的内存组成。这样的 strings 表现为深层拷贝。
* 传递底层资源的所有权。在某些特殊场合，你可能希望确保只有一个 RAII 对象引用一个裸资源（raw resource），而当这个 RAII 对象被拷贝的时候，资源的所有权从被拷贝的对象传递到拷贝对象。就像 Item 13 所说明的，这就是使用 auto_ptr 时“拷贝”的含意。
拷贝函数（copying functions）（拷贝构造函数和拷贝赋值运算符）可能是由编译器生成的，所以除非编译器生成的版本所做的事正是你所要的（Item 5 说明了这些缺省行为），你应该自己编写它们。在某些情况下，你也要支持这些函数的泛型化版本。这样的版本在 Item 45 描述。
Things to Remember
拷贝一个 RAII 对象必须拷贝它所管理的资源，所以资源的拷贝行为决定了 RAII 对象的拷贝行为。
普通的 RAII 类的拷贝行为不接受拷贝和进行引用计数，但是其它行为是有可能的。
- Preface（前言）
- Introduction（导言）
- Terminology（术语）
- Item 1: 将 C++ 视为 federation of languages（语言联合体）
- Item 2: 用 consts, enums 和 inlines 取代 #defines
- Item 3: 只要可能就用 const
- Item 4: 确保 objects（对象）在使用前被初始化
- Item 5: 了解 C++ 为你偷偷地加上和调用了什么函数
- Item 6: 如果你不想使用 compiler-generated functions（编译器生成函数），就明确拒绝
- Item 7: 在 polymorphic base classes（多态基类）中将 destructors（析构函数）声明为 virtual（虚拟）
- Item 8: 防止因为 exceptions（异常）而离开 destructors（析构函数）
- Item 9: 绝不要在 construction（构造）或 destruction（析构）期间调用 virtual functions（虚拟函数）
- Item 10: 让 assignment operators（赋值运算符）返回一个 reference to *this（引向 *this 的引用）
- Item 11: 在 operator= 中处理 assignment to self（自赋值）
- Item 12: 拷贝一个对象的所有组成部分
- Item 13: 使用对象管理资源
- Item 14: 谨慎考虑资源管理类的拷贝行为
- Item 15: 在资源管理类中准备访问裸资源（raw resources）
- Item 16: 使用相同形式的 new 和 delete
- Item 17: 在一个独立的语句中将 new 出来的对象存入智能指针
- Item 18: 使接口易于正确使用，而难以错误使用
- Item 19: 视类设计为类型设计
- Item 20: 用 pass-by-reference-to-const（传引用给 const）取代 pass-by-value（传值）
- Item 21: 当你必须返回一个对象时不要试图返回一个引用
- Item 22: 将数据成员声明为 private
- Item 23: 用非成员非友元函数取代成员函数
- Item 24: 当类型转换应该用于所有参数时，声明为非成员函数
- Item 25: 考虑支持不抛异常的 swap
- Item 26: 只要有可能就推迟变量定义
- Item 27: 将强制转型减到最少
- Item 28: 避免返回对象内部构件的“句柄”
- Item 29: 争取异常安全（exception-safe）的代码
- Item 30: 理解 inline 化的介入和排除
- Item 31: 最小化文件之间的编译依赖
- Item 32: 确保 public inheritance 模拟 "is-a"
- Item 33: 避免覆盖（hiding）“通过继承得到的名字”
- Item 34: 区分 inheritance of interface（接口继承）和 inheritance of implementation（实现继承）
- Item 35: 考虑可选的 virtual functions（虚拟函数）的替代方法
- Item 36: 绝不要重定义一个 inherited non-virtual function（通过继承得到的非虚拟函数）
- Item 37: 绝不要重定义一个函数的 inherited default parameter value（通过继承得到的缺省参数值）
- Item 38: 通过 composition（复合）模拟 "has-a"（有一个）或 "is-implemented-in-terms-of"（是根据……实现的）
- Item 39: 谨慎使用 private inheritance（私有继承）
- Item 40: 谨慎使用 multiple inheritance（多继承）
- Item 41: 理解 implicit interfaces（隐式接口）和 compile-time polymorphism（编译期多态）
- Item 42: 理解 typename 的两个含义
- Item 43: 了解如何访问 templatized base classes（模板化基类）中的名字
- Item 44: 从 templates（模板）中分离出 parameter-independent（参数无关）的代码
- Item 45: 用 member function templates（成员函数模板） 接受 "all compatible types"（“所有兼容类型”）
- Item 46: 需要 type conversions（类型转换）时在 templates（模板）内定义 non-member functions（非成员函数）
- Item 47: 为类型信息使用 traits classes（特征类）
- Item 48: 感受 template metaprogramming（模板元编程）
- Item 49: 了解 new-handler 的行为
- Item 50: 领会何时替换 new 和 delete 才有意义
- Item 51: 编写 new 和 delete 时要遵守惯例
- Item 52: 如果编写了 placement new，就要编写 placement delete
- 附录 A. 超越 Effective C++
- 附录 B. 第二和第三版之间的 Item 映射