条款14：在资源管理中心小心copy行为之重难点

不仅仅动态分配的内存是资源，像文件描述器，互斥锁，数据库连接，以及网络sockets等也是资源，如果不及时关闭，也会造成资源浪费。

重点1：建立自己的资源管理类

如果是heap-based资源，则可以用auto_ptr或shared_ptr管理资源。然而并非所有资源都是heap-based，这样，就需要建立自己的资源管理类。

以互斥锁为例，为确保不会忘记将一个被锁住的mutex解锁，我们希望建立一个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 m1(&m);	
  ...
}

难点1：RAII class copying行为
如果上面Lock对象被复制，会发生什么事？

Lock m11(&m); 	       //锁定m                                                  
Lock m12(&m11);	       //将m11复制到m12身上 

这是一个一般化问题的特定例子：当一个RAII 对象被复制，会发生什么事？大多时候，选择下面两种可能：

1）禁止复制。

class Uncopyable
{
protected:    	      	    //允许继承对象构造和析构                            
  Uncopyable(){}
  ~Uncopyable(){}
private:
  Uncopyable(const Uncopyable &);     //但阻止copy                              
  Uncopyable &operator=(const Uncopyable&);
};

<span style="font-family: Arial, Helvetica, sans-serif; background-color: rgb(255, 255, 255);">为阻止Lock对象被复制，我们唯一需要做的就是继承Uncopyable:</span>

<span style="font-family: Arial, Helvetica, sans-serif; background-color: rgb(255, 255, 255);"></span><pre name="code" class="cpp">class Lock:private Uncopyable
{
public:
  ...
};

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

有时候我们希望保有资源，直到它的最后一个使用者被销毁。这个时候使用tr1::shared_ptr来引用计数。但是tr1::shared_ptr的缺省行为是“当引用次数为0时”删除其所指物，那不是我们的行为。当我们用上Mutex，我们想要做的释放动作是解锁而不是删除。

这可以给tr1::shared_ptr指定删除器来实现：

class Lock
{
public:
  explicit Lock(Mutex* pm):mutexPtr(pm,unlock)	  //unlock为指定的删除器        
  {
    lock(mutexPtr.get());     	      	      	  //get为显示转换函数           
  }
private:
  std::tr1::shared_ptr<Mutex> mutexPtr;	      	  //使用shared_ptr代替原始指针  
};

注意1：shared_ptr有两个参数，第一个是类型，第二个指定删除器，一般是函数，第二个参数可以省略，表示默认是删除对象。

注意2：本例的Lock class不再声明析构函数。class析构函数会自动调用其non-static成员变量的析构函数。