《Effective C++》Item14:在资源管理类中当心拷贝操作

条款13中引入了这样的概念:资源取得的时机便是初始化资源管理对象的时机。然而,资源的种类是很多的,我们总是需要编写自己的资源管理类。

例如,假设我们使用C风格的API来处理类型为Mutex的互斥量对象,提供了两种操作:锁定操作lock,以及解锁操作unlock

void lock(Mutex *mutex);
void unlock(Mutex *mutex);

为了确保绝对不会忘记将一个被锁定的互斥量解锁,我们需要建立一个资源管理类:

class MutexGuard
{
public:
    explicit Lock(Mutex *mutex) : _mutex(mutex) 
    {
        lock(_mutex);
    }

    ~Lock() 
    {
        unlock(_mutex);
    }

private:
    Mutex *_mutex;
};

用户对于MutexGuard类的使用符合RAII方式:

Mutex m;

//..
{
    MutexGuard guard(&m);
}
//..

这段代码目前运行良好。但是当MutexGuard对象被复制,将会发生什么?

MutexGuard guard1(&m); 
MutexGuard guard2(guard1);  

对于RAII资源管理类的设计者而言,这是一个一般化的问题,并且往往只有以下四种可能:

  • 禁止复制。很多时候对RAII对象的复制操作并不合理(例如,对于同一个网络连接,从逻辑上不应该存在两个管理对象),这时可以使用条款6的方法禁用复制操作。

  • 对底层资源使用引用计数。有时候我们希望一直持有资源,直到它的最后一个使用者被烧毁。这种情况下可以允许复制RAII对象,但是应该同时递增其引用计数。std::shared_ptr就是这样做的。

  • 复制底层资源。也就是说,对这个资源进行深度拷贝。例如,std::string对象内含有一个指向堆内存的指针。当这样的一个字符串对象被复制,不论是这个指针,还是其所指向的内存,都被制作出了一个复件。

  • 转移底层资源的所有权。某些场合下我们可能希望确保永远只有一个RAII对象指向一个底层资源,即使是这个RAII被复制的时候也应该如此。这样一来,就需要将底层资源的所有权进行转移,这是std::auto_ptr的实现方案。

最后,拷贝构造函数和拷贝赋值运算符可能会被编译器自动创建出来,因此除非编译器生成的版本做了我们需要的工作,否则我们应该自己编写它们(相关的信息,可以参阅条款5)。

【注意】
复制RAII对象必须要考虑其底层的资源,可以考虑禁止拷贝、引用计数、深度拷贝、转移所有权等合理做法。

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值