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

请牢记:

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

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

 

auto_ptr和tr1::shared_ptr的观念表现在heap_based资源上。然而并非所有资源都是heap_based,对于非heap_based资源而言,需要建立自己的资源管理类。

假设我们使用C API函数出来类型为Mutex的互斥器对象(mutex objects),共有lock和unlock两个函数。

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

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

为确保绝不会忘记将一个被锁住的Mutex解锁,创建一个Lock 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 ml(&m);    //锁定互斥器

...

}   //在区块末尾,自动解除互斥器锁定

如果此时Lock对象被复制:

Lock ml1(&m);    //锁定m

Lock ml2(ml1);   //将ml1复制到ml2上,会发生什么?

可能有以下两种选择:

禁止复制:许多时候允许RAII对象复制并不合理:

 

如果没有按需要定义复制构造函数和赋值操作符,那么得到的结果通常是:非内存资源被创建一次,释放多次。
禁止方式:将copying操作声明为private。

class Lock : private Uncopyable  //禁止复制。见条款6
{ public: ...            //如前 };

如果需要复制,重新定义复制构造函数和赋值操作符是必须的。
怎么写它们是一个问题,具体的方案依赖于实际的需要,可以使用深拷贝,也可以使用类似于 shared_ptr 的引用计数机制,或者传递所有权。

对底层资源采用引用计数法

复制RAII对象时,将该资源的“被引用数”递增。例:shared_ptr。

shared_ptr的缺省行为是“当引用次数为0时删除所指物”,但是上面的例子我们想要的动作是解除lock而非删除。
好在shared_ptr允许指定“删除器”:

class Lock

{

public:

    explicit Lock(Mutex* pm):mutexPtr(pm,unlock)  //以某个mutex初始化shared_ptr,并以unlock函数为删除器

    {lock(mutexPtr.get());}               //条款15



    ~Lock(){unlock(mutexPtr);}           //释放资源

private:

    std::tr1::shared_ptr<Mutex> mutexPtr;

};

深度拷贝:
某些标准字符串类型是“指向heap内存”之指针构成。这样的字符串对象被复制,不论指针或其所指内存都会被制作出一个复件。这样的字符串展现深度复制行为。

转移底部资源的拥有权:

auto_ptr奉行的复制意义:RAII对象被复制,资源的拥有权从被复制物转移到目标物。

 

你可能感兴趣的:(copy)