Effective C++:条款14:在资源管理类中小copying行为

(一)

上一条款说的auto_ptr和tr1::share_ptr适合于heap-based的资源,然而并不是所有资源都是heap-based的。换句话说并不是tr1::shared_ptr 和 auto_ptr 永远适合做为资源的管理者。所以有时难免还是需要实现自己的资源管理类型。

假设Mutex类型通过lock和unlock两组函数进行互斥器的锁定和解锁,可能我们希望和auto_ptr一样的行为,在某个智能类型析构时主动调用unlock进行解锁。比如下面的代码:

void lock(Mutex* pm); 
void unlock(Mutex* pm); 
class Lock{ 
public: 
    explicit Lock(Mutex* pm) : mutexPtr(pm) 
    { 
        lock(mutexPtr); //获得资源 
    } 

    ~Lock(){ unlock(mutexPtr); } //释放资源 
private: 
    Mutex *mutexPtr; 
};

当我们Lock对象进行copy时会发生什么,如下:

Mutex m;
Lock m11(&m);
Lock m12(m11);  //进行copy行为

导致的恶果就是将会对同一个资源释放两次。

(二)解决方法:

解决办法一:禁止复制。

如果复制动作对于RAII class并不合理的话,我们便应该禁止之!

回见条款6!声明一个Uncopyable类,把RAII class的copying操作声明为Uncopyable类的private。然后再继承之:

class Lock : private Uncopy{ //禁止复制,见条款6
	...
};


解决方法二:对底层资源祭出“引用计数法”(reference counting)。

有时候我们希望保有资源,直到它的最后一个使用者(某对象)被销毁。通常只要引用一个tr1::shared_ptr成员变量便可实现出reference_counting copy行为,但此时,tr1::shared_ptr的缺省行为是“当引用次数为0时删除其所指物”,那不是我们所要的行为,我们想要做的释放动作是解除锁定而非删除!

幸运的是,tr1::shared_ptr允许我们指定所谓的“删除器”(deleter),当引用次数为0时被调用,(此机能并不存在于auto_ptr)。删除器对tr1::share_ptr构造函数而言是可有可无的第二个参数:

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

所以在以后当引用次数为0时unlock函数就会被调用。如果没有设置unlock这个删除器,那么对象所指资源就会被删除,那不是我们所想要的结果!

解决方法三:复制底部资源

可以对一份资源拥有其任意数量的复件。复制资源管理对象时是“深度拷贝”。不仅指针会被制作出一个复件,而且会创建一个新的内存。

标准字符串类型是由指向heap内存的指针构成,当这样一个字符串对象被复制,不论指针还是其所指内存都会被复制一个复件。这样的字符串展现“深度复制”。

 

解决方法四:转移底部资源的拥有权

你希望确保只有一个RAII对象指向一个未加工资源,即使RAII被复制依然如此。资源的拥有权从被复制转移到目标物。这其实就是auto_ptr的复制意义。

 

 

请记住:

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

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

Effective C++:条款14:在资源管理类中小copying行为,布布扣,bubuko.com

Effective C++:条款14:在资源管理类中小copying行为

上一篇:Python调用微博API


下一篇:《Javascript权威指南》学习笔记之十六:BOM之源---BOM基本应用