Effective C++：条款14：在中小企业资源管理copying表现

（一）

在一项条款说法auto_ptr和tr1::share_ptr适合heap-based资源。然而，并非所有的资源都heap-based的。换句话说不tr1::shared_ptr 和 auto_ptr 总是适合作为资源管理器。管理类型。

如果Mutex类型通过lock和unlock两组函数进行相互排斥器的锁定和解锁，可能我们希望和auto_ptr一样的行为。在某个智能类型析构时主动调用unlock进行解锁。

比方以下的代码：

void lock(Mutex* pm);
void unlock(Mutex* pm);
class Lock{
public:
explicit Lock(Mutex* pm) : mutexPtr(pm)
{
lock(mutexPtr); //获得资源
}

~Lock(){ unlock(mutexPtr); } //释放资源
private:
Mutex *mutexPtr;
};

当我们Lock对象进行copy时会发生什么，例如以下：

Mutex m;
Lock m11(&m);
Lock m12(m11);  //进行copy行为

导致的恶果就是将会对同一个资源释放两次。

（二）解决方法：

解决的方法一：禁止复制。

假设复制动作对于RAII class并不合理的话。我们便应该禁止之！

回见条款6。声明一个Uncopyable类。把RAII class的copying操作声明为Uncopyable类的private。

然后再继承之：

class Lock : private Uncopy{ //禁止复制，见条款6
...
};

解决方法二：对底层资源祭出“引用计数法”（reference counting）。

有时候我们希望保有资源，直到它的最后一个使用者（某对象）被销毁。

通常仅仅要引用一个tr1::shared_ptr成员变量便可实现出reference_counting copy行为。但此时，tr1::shared_ptr的缺省行为是“当引用次数为0时删除其所指物”，那不是我们所要的行为，我们想要做的释放动作是解除锁定而非删除！

幸运的是。tr1::shared_ptr同意我们指定所谓的“删除器”（deleter），当引用次数为0时被调用，（此机能并不存在于auto_ptr）。

删除器对tr1::share_ptr构造函数而言是可有可无的第二个參数：

class Lock{
public:
explicit Lock(Mutex* pm) : mutexPtr(pm, unlock);  //以某个Mutex初始化shared_ptr，并以unlock函数为删除器
{
lock(mutexPtr.get());
}
private:
tr1::shared_ptr<Mutex> mutexPtr;
};

所以在以后当引用次数为0时unlock函数就会被调用。

假设没有设置unlock这个删除器，那么对象所指资源就会被删除，那不是我们所想要的结果。

解决方法三：复制底部资源

能够对一份资源拥有其随意数量的复件。

复制资源管理对象时是“深度拷贝”。不仅指针会被制作出一个复件。并且会创建一个新的内存。

标准字符串类型是由指向heap内存的指针构成。当这样一个字符串对象被复制，不论指针还是其所指内存都会被复制一个复件。

这种字符串展现“深度复制”。

解决方法四：转移底部资源的拥有权

你希望确保仅仅有一个RAII对象指向一个未加工资源，即使RAII被复制依旧如此。

资源的拥有权从被复制转移到目标物。这事实上就是auto_ptr的复制意义。

请记住：

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

（2）普遍而常见的RAII class copying行为是：抑制copying、引用计数法的实现。

但其他动作也很可能被实现。