Effective C++ 条款14:在资源管理器中小心coping行为

上节是对资源的管理说明,有时候我们不能依赖于shared_ptr或者auto_ptr,所以我们需要自己建立一个资源管理类来管理自己的资源。

例如建立一个类来管理Mutex锁,现在使用函数处理类型为Mutex的互斥器对象

class Lock{
public:
    explicit Lock(Mutex* mu):mutexPtr(mu)
    {
        lock(mutexPtr);
    }
    ~Lock()
    {
        unlock(mutexPtr);
    }
private:
    Mutex* mutexPtr;
};


void lock(Mutex* mu);//加锁
void unlock(Mutex* mu);//解锁

Mutex m;//定义互斥器
……
{
    Lock(&m);
    ……
}

以上代码可以完成对资源的释放,这里的释放对于mutex来说的真正意义就是解锁,而不是销毁。

然而,以上代码是有问题的,比如执行Lock m2(m1);这句话时,我们需要怎么面对?难道就是两个对象交互的操纵mutex?这样做绝对不行,我们不能确定什么时候m2和m1会被析构,一旦被析构就会导致mutex解锁,mutex一旦解锁就会被别的进程所调用,程序将出现巨大的混乱!

解决上述问题一般有以下几种方式:

  1. 禁止复制
    许多情况下,复制RAII对象并不合理。例如Lock类,这时候便可以禁止复制,只需将coping函数设为私有,条款6有讲述

  2. 对管理资源使用引用计数法。
    模仿shared_ptr。shared_ptr指针类型可以复制,多个该类型指针指向同一对象也没关系。当一个被析构,mutex也不会被析构,当所有shared_ptr被析构,即引用为0,mutex才会被析构(调用删除器)。

.

  • 第一种
class Lock:private Uncopyable{  //禁止复制。见条款6
public:
    ...                          //如前
};
  • 第二种
class Lock{
public:
    explicit Lock(Mutex* pm):mutexPtr(pm,unlock)//以某个Mutex初始化shared_ptr
                                                //并以unlock函数为删除器
    {
        lock(mutexPtr.get());
    }
private:
    std::tr1::shared_ptr<Mutex> mutexPtr; //使用shared_ptr替换raw pointer
};

如果上述Lock类使用引用计数器的话,只需把mutexPrt从Mutex*类型变为shared_ptr类型即可。但shared_ptr默认是当引用计数为0时,删除多指向对象,这不是我们想要的,我们想要的是调用unlock函数。幸运的是在shared_ptr中允许指定“删除器”,即引用计数为0时调用的函数。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值