条款14:在资源管理类中小心copying

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq_34938530/article/details/88957278

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

  

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

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

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

 使用者对Lock的用法符合RAII方式:

Mutex m;            //定义你需要的互斥器
...
{                   //建立一个区块用来定义critical section
    Lock m1(m);     //锁定互斥器
    ...             //执行critical section内的操作
                    //在区块最末尾,自动解除互斥器锁定
}

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

  

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

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

  (1)禁止复制。许多时候允许RAII对象被复制并不合理。对一个像Lock这样的class这是有可能的,因为很少能够合理拥有“同步基础器物”(synchronization primitives)的复件。如果复制动作对RAII并不合理,你便应该禁止。可以将copying操作申明为private(见条款06)。对Lock而言看起来是这样:

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

(2)对底层资源祭出“引用计数法(reference-conut)”。有时候我们希望保有资源,直到它的最后一个使用者被销毁。这种情况下复制RAII对象时,应该将资源的“被引用数”递增。tr1::shared_ptr便是如此。

  str::shared_ptr允许指定所谓的“删除器”(deleter),那是一个函数或函数对象,当引用次数为0时便被调用(auto不存在此机能,它总是将其指针删除)。删除器对tr1::shared_ptr构造函数而言是可有可无的第二参数。

class Lock
{
public:
    explicit Lock(Mutex* pm) //以某个Mutex初始化shared_ptr,并以unlock函数为删除器 
    : mutexPtr(pm,unlock) 
    {
        lock(mutexPtr.get());//tr1::shared_ptr和auto_ptr都提供一个get成员函数,用来执行显示转            
                              //换,也就是它会返回智能指针内部的原始指针
    }
private:
    std::tr1::shared_ptr<Mutex> mutexPtr; //使用shared_ptr替换raw pointer
};

 (3)复制底部资源 某些标准字符串类型是“指向heap内存”之指针构成*(那内存被用来存放字符串的组成字符)。这种字符串对象内含一个指针指向heap内存。当这样一个字符串对象被复制,不论指针或其所指内存都会被制作成一个复件。这样的字符串展现深度复制行为。

 (4)转移底部资源的拥有权。某些罕见场合下你可能希望确保永远只有一个RAII对象指向一个未加工资源,即使RAII对象被复制依然如此。此时资源的拥有权会被复制物转移到目标物。

  结论:

  复制RAII对象必须一并复制它所管理的资源,所以资源的copying行为决定RAII对象的copying行为。

  普遍而常见的RAII class copying行为是:抑制copying、施行应用计数法。不过其他行为也可能被实现。

猜你喜欢

转载自blog.csdn.net/qq_34938530/article/details/88957278