精通C++资源管理-在资源管理类中小心coping行为

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

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

计算中的资源是个非常广泛的概念，内存、锁、文件、Socket等等都是资源，C++中可以通过统一的方式管理这些资源，即RAII。然而，并非所有资源都是heap-based的。而auto_ptr和shared_ptr是将观念表现在heap-base资源上，因此，我们有可能偶而需要建立自己的资源管理类。

下面举一个使用Mutex的互斥器对象的例子。

为确保我们绝不会忘记将一个被锁住的Mutex解锁，因此建立这样一个class用来管理锁。

class Lock

{

public:

explicit Lock(Mutex* pm) 

:mutexPtr(pm,unlock)

{lock(mutexPtr);}

~Lock(){unlock(mutexPtr);}

private:

Mutex* mutexPtr;

};

对于上面这个Lock类，

Mutex m;

Lock m11(&m);

Lock m12(m11);//将mll复制到m12身上，这会发生什么事？？

一般这时候，会选择以下两种可能：

• 禁止复制
• 对底层资源使用“引用计数法”(reference-count)。tr1::shared_ptr便是如此。

在这里，只要用shared_ptr<Mutex>替换上面的Mutex*，便可实现出reference-counting coping 行为。然而很不幸的是，shared_ptr的缺省行为是“当引用次数为0时删除其所指物”，这当然不是我们所要的行为。当我们用上一个Mutex，我们想要做的释放动作是解除锁定而非删除。

幸运的是，shared_ptr允许指定所谓的"删除器"，那是一个函数或函数对象，当引用次数为0时便被调用(注意的是，auto_ptr并不存在此机能，它总是将其指针删除)。

删除器对shared_ptr构造函数而言是可以可无的第二个参数。所以代码看起来像这样：

class Lock

{

public:

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

:mutexPtr(pm,unlock)

{lock(mutexPtr.get());}

private:

shared_ptr<Mutex> mutexPtr; //使用shared_ptr替换之

};

请注意，本例的Lock类不再声明析构函数。因为没有必要。class析构函数（无论自己写的还是编译器生成的）会自动调用其non-static成员变量（本例为mutexPtr）的析构函数。而mutexPtr的析构函数会在互斥器的引用计数为0时自动调用shared_ptr的删除器（本例为unlock）。