Effective C++读书笔记之十四：在资源管理类中小心copying行为

Item 14：Think carefully about copying behavior in resource-managing classes

条款13导入这样的观念：“资源取得时机便是初始化时机”，并以此作为“资源管理类”的脊柱。然而当一个RAII对象被复制，会发生什么事？大多数时候你会选择以下四种可能。

禁止复制：许多时候允许RAII对象被复制并不合理，因为很少能够合理拥有“同步化基础器物”的复件（副本）。如果复制动作对RAII class并不合理，你便应该禁止之。条款6告诉你怎么做：将copying操作声明为private。

对底层资源祭出“引用计数法”：有时候我们希望保有资源，直到它的最后一个使用者（某对象）被销毁。这种情况下复制RAII对象时，应该将资源的“被引用数”递增。tr1:shared_ptr便是如此。

tr1:shared_ptr允许指定所谓的“删除器”，那是一个函数或函数对象，当引用次数为0时便被调用。删除器对tr1: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,unlock)
	{
		lock(mutexPtr.get());
	}
private:
	std::tr1::shared_ptr<Mutex> mutexPyr;
}

复制底部资源：你需要“资源管理类”的唯一理由是，当你不再需要某个复件时确保它被释放。在此情况下复制资源管理对象，应该同时也复制其所包覆的资源。也就是说，复制资源管理对象时，进行的是深度拷贝。

转移底部资源的所有权：某些罕见场合下你可能希望确保永远只有一个RAII对象指向一个未加工资源，即使RAII对象被复制依然如此，此时对象的所有权会从被复制物转移到目标物。

copying函数可能被编译器自动创建出来，因此除非编译器所生版本做了你想要做的事，否则你得自己编写它们。

请注意：

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

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