Effective C++条款14——在资源管理类中小心coping行为（资源管理）

最新推荐文章于 2024-11-12 15:18:48 发布

StudyWinter

最新推荐文章于 2024-11-12 15:18:48 发布

阅读量281

点赞数

本文链接：https://blog.csdn.net/Zhouzi_heng/article/details/132459924

版权

Effective C++ 专栏收录该内容

24 篇文章 0 订阅

订阅专栏

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

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

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

为确保绝不会忘记将一个被锁住的 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);    // 建立一个区块用来定义关键部分
                    // 锁定互斥器
                    // 执行相关代码
}                   // 自动解除互斥器锁定

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

Lock m11(&m);            // 锁定m
Lock m12(&m11);          // 将m11复制到m12上，会发生什么

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

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

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

对底层资源祭出“引用计数法”(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的缺省行为是“当引用次数为О时删除其所指物”，那不是我们所要的行为。当我们用上一个Mutex,我们想要做的释放动作是解除锁定而非删除。

幸运的是 tr1::shared_ptr 允许指定所谓的“删除器”(deleter），那是一个函数或函数对象（function object），当引用次数为0时便被调用（此机能并不存在于auto_ptr——它总是将其指针删除）。删除器对tr1::shared _ptr构造函数而言是可有可无的第二参数，所以代码看起来像这样:

class Lock {
public:
    explicit Lock(Mutex* pm)
        :mutexPtr(pm, unlock)
        {
            lock(mutexPtr.get());
        }

private:
    std::tr1::shared_ptr<Mutex> mutexPtr;        // 使用shared_ptr代替
};

请注意，本例的Lock class不再声明析构函数。因为没有必要。条款5说过,class析构函数(无论是编译器生成的,或用户自定的)会自动调用其non-static成员变量（本例为mutexPtr)的析构函数。而
mutexPtr的析构函数会在互斥器的引用次数为0时自动调用tr1::shared_ptr的删除器（本例为unlock）。(当你阅读这个class的原始码，或许会感谢其中有条注释指出:你并没有忘记析构，你只是倚赖了编译器生成的缺省行为。)

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

Coping函数（包括copy构造函数和copy assignment操作符）有可能被编译器自动创建出来，因此除非编译器所生版本做了你想要做的事（条款5提过其缺省行为），否则你得自己编写它们。某些情况下你或许也想支持这些函数的一般版本，这样的版本描述于条款45。

请记住