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

假如我们使用C API函数处理类型为Mutex的互斥对象，共有lock和unlock两函数可用：

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

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

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

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

class Lock
Mutex m;//定义你需要的互斥器
...
{  //建立一个区块来定义critical section
Lock(&m);//锁定互斥器
...//执行critical section内的操作

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

这很好，但是如果Lock对象被复制，会发生什么？

Lock m1(&m);//锁定
Lock m2(m1);//复制

当一个RAII对象被复制，会发生什么，大多数时候有以下几种选择：

1.禁止复制

许多时候允许RAII对象被复制并不合理。对一个像Lock这样的类这是可能的，因为很少能够合理拥有“同步化基础物”的副本。如果复制对RAII并不合理，你应该禁止复制。条款6告诉我们怎么做：将copying操作声明为private，对Lock而言看起来是这样的：

class Lock : private Uncopyable//禁止复制
{
public:
  ..
};

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

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

通常只要内含一个tr1::shared_ptr成员变量，RAII类便可实现出引用计数行为。如果前述Lock打算使用使用技术，它可以改变mutexPtr类型，将它从Mutex*改为tr1::shared_ptr<Mutex>。然而不幸tr1::shared_ptr的缺省行为是“当引用次数为0时删除其所指物”，那不是我们所要的行为。幸运的是tr1::shared_ptr允许指定所谓的“删除器”，那是一个函数或函数对象，当引用次数为0时便调用。删除器对tr1::shared_ptr构造函数而言是可有可无的第二参数，所以代码看起来像这样：

class Lock
{
public:
  explicit Lock(Mutex *pm)//以某个Mutex初始化shard_ptr并以unlock函数
    :mutexPtr(pm, unlock) //为删除器
  {
    lock(mutexPtr.get());//条款15谈到 get
  }
private:
  std::tr1::shared_ptr<Mutex> mutexPtr; //使用shared_ptr
};

本例的Lock不再声明析构函数，因为没有必要。条款5说过，类的析构函数会自动调用其non_static成员变量的析构函数。而mutexPtr的析构函数会在互斥器的引用次数为0的时候自动调用tr1::shared_ptr的删除器。

3.复制底层资源

有时候只要你喜欢，可以针对一份资源拥有其任意数量的副件，而你需要“资源管理类”的唯一理由是，当你不再需要某个副本的时候确保它被释放，在此情况下复制资源管理对象，应该同时也复制其所包覆的资源，也就是说，复制资源管理了对象时，进行的是“深度拷贝”。

4.转移底部资源的拥有权

某些罕见场合下你可能希望确保永远只有一个RAII对象指向一个未加工资源，即使RAII对象被复制依然如此。此时资源的拥有权会从被复制物转移到目标物。如条款13所诉。这是atuo_ptr奉行的复制意义。

 

copying函数有可能被编译器自动创建出来，因而除非编译器所生成版本做了你想要做的事情，否则你的自己编写它们。某些情况下你或许也想支持这些函数版本，这样的版本描述于条款45

 

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

普通而常见的RAII类copying行为是：抑制copying，施行引用计数法，不过其他行为都可能被实现。