C++条款在资源管理类中小心copying行为

最新推荐文章于 2022-10-19 00:11:41 发布

MisakiJh

最新推荐文章于 2022-10-19 00:11:41 发布

阅读量292

点赞数

分类专栏： C++条款

本文链接：https://blog.csdn.net/MisakiJh/article/details/88853704

版权

C++条款专栏收录该内容

13 篇文章 2 订阅

订阅专栏

在资源管理类中小心copying行为

Think carefully about copying behavior in resource-managing classes

上个条款中，我们导入这样的观念：“资源取得时机便是初始化时机”(RAII)，也描述了auto_ptr和tr1::shared_ptr如何将这个观念表现在heap-based资源上。然而并非所有资源都是heap-based，对那种资源而言，像auto_ptr和tr1_shared_ptr这样的智能指针往往不适合作为资源掌管者。既然如此，有可能偶尔你会发现，你需要建立自己的资源管理类。

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

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

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

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

class Lock{
public:
    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(&ml1);    //将ml1复制到ml2身上。这会发生什么事？

这是某个一般化问题的特定例子。那个一般化问题是每一位RAII class作者一定需要面对的：“当一个RAII对象被复制，会发生什么事情？”大多数时候你会有两种选择：

禁止复制。

如果复制动作对RAII class并不合理，你便应该禁止之。将copying操作声明为private，是可行的。

对底层资源祭出“引用计数法”(reference-count)

有时候我们希望保有资源，直到它的最后一个使用者（某对象）被销毁。这种情况下复制RAII对象时，应该将资源的“被引用数”递增。这也是我最喜欢的一个方法。

正常情况下，只要内含一个tr1::shared_ptr成员变量，RAII classes便可实现出reference-counting copying行为。如果前述的Lock打算使用reference counting，它可以改变mutexPtr的类型，将它从Mutex*改为tr1::shared_ptr<Mutex>。然而很不幸tr1::shared_ptr的缺省行为是“当引用次数为0时删除其所指物”，那不是我们所要的行为。我们要做的释放动作是解除锁定而非删除。

幸运的是tr1::shared_ptr允许指定所谓的“删除器”(deleter)，那是一个函数或函数对象，当引用次数为0时便被调用。删除器对tr1::shared_ptr构造函数而言是可有可无的第二参数，所以代码看起来像这样：

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

请注意，本例的Lock class不再声明析构函数。因为没有必要。因为class析构函数会自动调用其non-static成员变量的析构函数。而mutexPtr的析构函数会在互斥器的引用次数为0时自动调用tr1::shared_ptr的删除器（本例为unlock）。