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

请牢记：

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

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

 

auto_ptr和tr1::shared_ptr的观念表现在heap_based资源上。然而并非所有资源都是heap_based，对于非heap_based资源而言，需要建立自己的资源管理类。

假设我们使用C API函数出来类型为Mutex的互斥器对象（mutex objects），共有lock和unlock两个函数。

void lock(Mutex* pm);		//锁定pm所指的互斥器

void unlock(Mutex* pm);		//将互斥器解除锁定

为确保绝不会忘记将一个被锁住的Mutex解锁，创建一个Lock class 来管理机锁。这样的class的基本结构由RAII守则支配，也就是“资源在构造期间获得，在析构期间释放”：

class Lock

{

public:

	explicit Lock(Mutex* pm)

		: mutexPtr(pm)

	{

		Lock(mutexPtr);		//获得资源

	}

	~Lock()

	{

		unlock(mutexPtr);	//释放资源

	}

private:

	Mutex *mutexPtr;

};

客户对Lock的用法符合RAII方式：

Mutex m;

...

{

Lock ml(&m);    //锁定互斥器

...

}   //在区块末尾，自动解除互斥器锁定

如果此时Lock对象被复制：

Lock ml1(&m);    //锁定m

Lock ml2(ml1);   //将ml1复制到ml2上，会发生什么？

可能有以下两种选择：

禁止复制：许多时候允许RAII对象复制并不合理：

 

如果没有按需要定义复制构造函数和赋值操作符，那么得到的结果通常是：非内存资源被创建一次，释放多次。
禁止方式：将copying操作声明为private。

class Lock : private Uncopyable　　//禁止复制。见条款6
{

public:

	...　　　　　　　　　　　　//如前

};

如果需要复制，重新定义复制构造函数和赋值操作符是必须的。
怎么写它们是一个问题，具体的方案依赖于实际的需要，可以使用深拷贝，也可以使用类似于 shared_ptr 的引用计数机制，或者传递所有权。

对底层资源采用引用计数法：

复制RAII对象时，将该资源的“被引用数”递增。例：shared_ptr。

shared_ptr的缺省行为是“当引用次数为0时删除所指物”，但是上面的例子我们想要的动作是解除lock而非删除。
好在shared_ptr允许指定“删除器”：

class Lock

{

public:

    explicit Lock(Mutex* pm):mutexPtr(pm,unlock)  //以某个mutex初始化shared_ptr，并以unlock函数为删除器

    {lock(mutexPtr.get());}　　　　　　　　　　     //条款15



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

private:

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

};

深度拷贝：
某些标准字符串类型是“指向heap内存”之指针构成。这样的字符串对象被复制，不论指针或其所指内存都会被制作出一个复件。这样的字符串展现深度复制行为。

转移底部资源的拥有权：

auto_ptr奉行的复制意义：RAII对象被复制，资源的拥有权从被复制物转移到目标物。