在资源管理器中小心copying行为
上节是对资源的管理说明，有时候我们不能依赖于shared_ptr或者auto_ptr,所以我们需要自己建立一个资源管理类来管理自己的资源。
例如建立一个类来管理Mutex锁，现在使用函数处理类型为Mutex的互斥器对象
class Lock{public:explicit Lock(Mutex* mu):mutexPtr(mu){lock(mutexPtr);}~Lock(){unlock(mutexPtr);}private:Mutex* mutexPtr;};unlock(Mutex* mu);//解锁Mutex m;//定义互斥器……{Lock(&m);……}
以上代码可以完成对资源的释放，这里的释放对于mutex来说的真正意义就是解锁，而不是销毁。
然而，以上代码是有问题的，比如执行Lock m2(m1);这句话时，我们需要怎么面对？难道就是两个对象交互的操纵mutex？这样做绝对不行，我们不能确定什么时候m2和m1会被析构，一旦被析构就会导致mutex解锁，mutex一旦解锁就会被别的进程所调用，程序将出现巨大的混乱！
解决上述问题一般有以下几种方式：
1、禁止复制 许多情况下，复制RAII对象并不合理。例如Lock类，这时候便可以禁止复制，只需将coping函数设为私有，条款6有讲述
2、对管理资源使用引用计数法。模仿shared_ptr
3、复制底部资源。这里要是深拷贝
4、转移底层资源的拥有权。模仿auto_ptr.
作者举出第二种方式的具体操作，如下：
class Lock：private Uncopyable{public:explicit Lock(Mutex* mu):mutexPtr(mu,unlock)//以某个Mutex初始化，unlock作为删除其{lock(mutexPtr);}private:shared_prt<Mutex> mutexPtr;};
如果上述Lock类使用引用计数器的话，只需把mutexPrt变为类型从Mutex*变为shared即可。但shared_ptr默认是当引用计数为0时，删除多指向对象，这不是我们想要的，我们想要的是调用unlock函数。幸运的是在shared_ptr中允许指定“删除器”，即引用计数为0时调用的函数。
，更有一种逍遥，浑然忘我，与大自然交融的境界令人心弛神往。
