条款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
对象必须要考虑其底层的资源,可以考虑禁止拷贝、引用计数、深度拷贝、转移所有权等合理做法。