Think carefully about copying behavior in resource-managing classes.
class Lock
{
public:
explict Lock(Mutex* pm) : _mutexPtr(pm) { lock(_mutexPtr); }
~Lock() { unlock(_mutexPtr); }
private:
Mutex* _mutexPtr;
};
Mutex m;
{
Lock ml(&m);
...
}
Lock ml1(m);
Lock mk2(ml1);
当一个 RAII 对象被复制时会发生什么事?有几种可能
有时候让 RAII 对象支持复制很不合理,比如 Lock 这种同步化器物(synchronize promitives),此时应该禁止复制,见条款 06
class Lock : private Uncopyable { ... };
可以将 Mutex* 改为 shared_ptr,然而 shared_ptr 的缺省行为是引用次数为 0 时删除所指之物,而这里我们希望当引用计数为 0 时 unlock,此时我们需要用到 share_ptr 默认省略的第二参数 deleter,用于指定删除动作
class Lock
{
public:
explict Lock(Mutex* pm) : _mutexPtr(pm, unlock) { lock(_mutexPtr.get()); }
private:
std::shared_ptr _mutexPtr;
};
当 _mutexPtr 引用计数为 0 时,会调用 unlock,这里不再需要 Lock 的析构函数来 unlock
当你需要资源管理类的唯一理由是希望不需要某个副本时将其释放,则可以使资源管理类再复制时做深度复制(deep copying)行为
某些情况会需要确保永远只有一个 RAII 对象指向一个资源,即使 RAII 对象被复制依然如此,此时资源的拥有权会从被复制物转移到目标物,正如 auto_ptr 所实现