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

最新推荐文章于 2022-12-19 16:43:50 发布

WhiteJunior

最新推荐文章于 2022-12-19 16:43:50 发布

阅读量340

点赞数

本文链接：https://blog.csdn.net/lym940928/article/details/81291992

版权

Self-Culture 同时被 3 个专栏收录

751 篇文章 5 订阅

订阅专栏

C/C++

127 篇文章 7 订阅

订阅专栏

Effective C++

39 篇文章 3 订阅

订阅专栏

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

Think carefully about copying behavior in resource-managing classes.

如果一个RAII对象被复制，会发生什么？

在上一个条款之中，提到了“资源获得的时机就是初始化时机”（Resource Acquisition Is Initialization（RAII）），并且说明了auto_ptr和tr1::shared_ptr如何在heap-based的资源上作用的。
但是，并不是所有的资源都是“heap-based”的，对于这种资源，上述的这两种指类指针对象就不再适合作为资源管理者了。于是，我们需要建立自己的资源管理类，

举个例子，加入使用C API函数处理类型为Mutex的互斥器对象（mutex objects），共有lock和unlock两个函数可以使用：

void lock(Mutex* pm);       //锁定pm所指的互斥器
void unlock(MUtex* pm);     //将互斥器解除锁定

为了确保不会忘记将一个被锁住的Mutex解锁，可能需要创建一个class来管理机锁。利用RAII的思想，即“资源在构造期间获得，在析构期间释放”：

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

在使用Lock时，符合RAII的标准：

Mutex m;        //定义所需要的互斥器
...
{               //建立一个区块用来定义critical section
Lock ml(&m);    //锁定互斥器
    ...         //执行critical section内的操作
}               //在区块结尾处，会自动解除互斥器的锁定

这样的操作的是没有问题，但是如果此时Lock对象被复制：

Lock ml1(&m);       //锁定m
Lock ml2(m1l);      //将ml1复制到ml2之上

“如果一个RAII对象被复制，会发生什么？”
这个时候，对于这种情况，一般有两种选择：

1，禁止复制。因为许多时候，允许RAII被复制并不合理。如果复制动作对于RAII对象不够合理，就应该禁止。实现这种禁止，即用到了条款6中所说的办法：将copying操作声明为private：

class Lock : private Uncopyable {   //禁止复制，详见条款6
public:
    ...           //同前
};

2，对底层资源去使用“引用计数法（reference-count）”。有的时候，我们希望保持着资源，直到它的最后一个使用者（某个对象）被销毁。在这种情况下，复制RAII对象时，应该将资源的“被引用数”进行递增。tr1::shared_ptr就是如此。

通常只要内含一个tr1::shared_ptr成员变量，RAII classes就可以实现reference-counting copying行为。假如前面的Lock想要使用reference counting，它可以直接去改变mutexPtr的类型即可：

将其从Mutex*改为tr1::shared_ptr< Mutex >.

但是，需要注意的是，tr1::shared_ptr的默认行为为：

当引用次数为0时，删除其所指物。

删除操作并不是我们想要的，当我们使用一个Mutex，我们要做的释放动作是解除锁定而并非删除。

因此，tr1::shared_ptr是允许定义所谓的“删除器（deleter）”的，这是一个函数或者函数对象（function object），当引用的次数为0时被调用（这个功能并不存在与auto_ptr中，它总是将其指针删除）。这个删除器对于tr1::shared_ptr是第二个参数：

class Lock {
public:
    explict Lock(Mutex* pm)   //以某个Mutex初始化shared_ptr
      : mutexPtr(pm, unlock)  //并且unlock函数作为删除器
      {
          lock(mutexPtr.get());   
      }
      //注意！没有析构函数！
private:
std::tr1::shared_ptr<Mutex> mutexPtr;   //使用shared_ptr代替raw pointer   
}；

需要注意的是，上面的Lock class**不在声明析构函数**，因为没有必要了。
在条款5中说过，无论是编译器自动生成的、还是用户自定义的，class 析构函数都会自动调用其non-static成员变量（在这里是mutexPtr）的析构函数。而mutexPtr的析构函数会在互斥器的引用计数为0时自动调用tr1::shared_ptr的删除器（在这里是unlock）。也就是说，之所以没有声明析构函数，完全只是依赖了编译器生成的缺省行为。

复制底部资源。有些时候，可以针对一份资源拥有任意数量的副本。而需要“资源管理类”的唯一理由就是：当不再需要某个复件时，确保它被释放。在这种情况下复制对象，应该同时复制这个对象对象所包含的所有资源。也就是说，复制资源管理对象时，进行的是“深度拷贝”。
对于某些标准字符串类型，它们是由“指向heap内存的指针”所构成的（这些内存被用来存放字符串所组成字符）。这种字符串对象内含一个指针，指向一块heap内存。当这样一个字符串对象被复制，无论指针还是其所指内存都会被制作出一个复件。这样的字符串所展现的就是深度拷贝（deep copying）行为。
转移底部资源的拥有权。在某些很少见的场合下，可能只希望确保永远只有一个RAII对象指向一个未加工资源（raw resource），即使是对RAII对象被复制依然如此。此时资源的拥有权会从被复制物转移到目标物。就像条款13所说，auto_ptr所执行的就是这样的复制。

Copying函数（包括copy构造函数和copy assignment操作符）有可能是编译器自动创建出来的。因此，除非编译器产生的版本真的做到了你想做的事情，否则，我们就必须重新进行编写copying函数。

最后，