Effective C++之条款14：在资源管理类中小心copying行为

声明：

1. 文中内容收集整理自《Effective C++（中文版）第三版》，版权归原书所有。
2. 本内容在作者现有能力的基础上有所删减，另加入部分作者自己的理解，有纰漏之处敬请指正。

---

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

Think carefully about copying behavior in resource-managing classes.

#include <iostream>
#include<mutex>
using namespace std;

class Lock
{
public:
	explicit Lock(mutex* pm) : mutexPtr(pm)
	{
		cout << "构造" << endl;
		mutexPtr->lock();
	}

	~Lock()
	{
		cout << "析构" << endl;
		mutexPtr->unlock();
	}

private:
	mutex* mutexPtr;
};


int main()
{
	mutex mtx;
	Lock m1(&mtx);
	Lock m2(m1);
	system("pause");
}

运行以上代码，结果如下：

 

也即是说，当复制一个 RAII对象时，发生了两次析构，导致了不明确行为。

理解以上代码，客户对Lock的用法符合RAII方式：

Mutex m; //定义互斥器
...
{
	Lock m1(&m); //锁定互斥器
	...
}

但是，当一个RAII对象被复制，会发生什么事情？运行以上代码可发现，程序运行完会有两个unlock被执行，会有不明确行为发生。大多数情况下会选择以下两种方案。

1. 禁止复制

许多时候允许RAII对象被复制并不合理。如果复制动作对RAII class并不合理，我们便应该禁止。条款6告诉了我们怎么做：继承一个Uncopyable class：

class Lock:private Uncopyable
{
public:
	...
};

2. 对底层资源祭出“引用计数法”

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

通常只要内含一个shared_ptr成员变量，RAII classes便可实现reference-counting copying行为。然而shared_ptr的缺省行为是“当引用次数为0时删除其所指物”，那不是我们所要的行为。而当我们用Mutex时，我们想做的释放动作是解除锁定而非删除。幸运的是shared_ptr允许指定所谓的“删除器（deleter）”，那是一个函数或函数对象，当引用次数为0时便被调用。删除器对shared_ptr构造函数而言是可有可无的第二参数，所以代码看起来像这样：

class Lock
{
public:
	explicit Lock(Mutex *pm) : mutexPtr(pm, unlock)
	{
		//以某个mutex初始化shared_ptr，并以unlock作为删除器
		// 删除器对tr::shared_ptr构造函数而言是可有可无的第二参数
		lock(mutexPtr.get()); //条款15将讲到get
	}
private:
	std::tr1::shared_ptr<mutex> mutexPtr;
};

请注意，本例的Lock class不再声明析构函数，因为没有必要。逻辑如下：class析构函数会自动调用其non-static成员变量（本例为mutexPtr）的析构函数。而mutexPtr的析构函数会在互斥器的引用次数为0时自动调用tr1::shared_ptr的删除器（本例为unlock）。

请记住：

赋值RAII对象必须一并复制它所管理的资源，所以资源的拷贝行为决定RAII对象的拷贝行为。

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