《Effective C++ 》学习笔记——条款14

***************************************转载请注明出处：http://blog.csdn.net/lttree********************************************

三、Resource Management

 

 

Rule 14：Think carefully about copying behavior in resource-managing classes.

规则 14：在资源管理中小心copying行为

1.引言

在条款13中导入了这样的一个概念：“资源获取的时机便是初始化时机”（RAII），并且以此作为“资源管理类”的脊柱，也描述了auto_ptr 和 tr1::shared_ptr如何将这个观念表现在 heap-based资源上。△然而并非所有的资源都是基于堆的，因此你有可能需要建立自己的资源管理类。△。

 

2.建立自己的资源管理类

假设我们使用C API 函数处理类型为 Mutex 的 互斥器 对象（mutex objects），共有lock 和 unlock两个函数使用：

<span style="font-family:Comic Sans MS;">void lock(Mutex* pm);    // 锁定互斥器
void unlock(Mutex* pm);    // 解锁互斥器</span>

为确保我们不会忘记将一个被锁住的 Mutex 解锁，可能会希望建立一个类来管理它，让类在析构期间释放它：

<span style="font-family:Comic Sans MS;">class Lock  {
public:
    explicit Lock(Mutex* pm) : mutexPtr(pm)
    {  lock(mutexPtr);  }
    ~Lock()  {  unlock(mutexPtr);  }
private:
    Mutex *mutexPtr;
};</span>

客户对于Lock的用法也会符合RAII方式：

<span style="font-family:Comic Sans MS;">Mutex m;    // 定义所需要的互斥器
...
{    // 建立一个区块来定义临界区
    Lock m1(&m);    // 锁定互斥器
    ...
}    // 在区块最末尾，自动解除互斥器锁定</span>

这很好，但如果Lock对象被复制，会怎样呢？

这是某个一般化问题的特定例子，但这个一般化问题是每一位RAII 类的作者一定需要面对的。

大多数情况下你会选择以下两种可能：

☆禁止复制

许多时候允许RAII对象被复制并不合理。禁用它，在条款6中告诉你如何做了：将copying操作声明为 private 。对于本例而言就是这样的：

<span style="font-family:Comic Sans MS;">class Lock : private Uncopyable  {
public:
    ...    // 同前一样
};</span>

☆对底层资源祭出“引用计数法”（reference-count）

有时候我们希望保有资源，直到它的最后的一个使用者（某对象）被销毁。这种情况下复制RAII对象时，应该将资源的“被引用数”递增。tr1::shared_ptr便是如此。

通常只要内含一个 tr1::shared_ptr 成员变量，RAII便可实现出reference-counting copying行为。如果前述的Lock打算打算使用 reference couting，它可以改变mutexPtr的类型，将它从Mutex* 改为 tr1::shared_ptr<Mutex>。然而很不幸tr1::shared_ptr的缺省行为是“当引用次数为0时删除所指物”，那不是我们所要的行为。但当我们用Mutex，需要的释放动作是 解锁 而非删除。

非常幸运的是，tr1::shared_ptr允许指定所谓的“删除器”（deleter），那是一个函数或函数对象，当引用次数为0时便被调用（此机能并不存在于auto_ptr）。删除器对于tr1::shared_ptr而言是 可有可无 的第二参数，所以代码是这样的：

<span style="font-family:Comic Sans MS;">class Lock  {
public:
    explicit Lock(Mutex* pm) : mutexPtr(pm,unlock)
    {
        lock(mutexPtr.get() );
    }
private:
    std::tr1::shared_ptr<Mutex> mutexPtr;    // 使用 shared_ptr 替换 raw pointer
};</span>

而且本例中的 Lock class 不再声明析构函数。因为没有必要。

△ 复制底部资源

有时候，只要你喜欢，可以针对一份资源拥有其任意数量的复件（副本）。而你需要“资源管理类”的唯一理由是，当你不再需要某个复件时，确保它被释放。在此情况下复制资源管理对象，应该同时也复制其所包含的资源，即复制对象时，进行“深度拷贝”。

某些标准字符串类型是由“指向堆内存”的指针构成。这种字符串对象内含一个指针指向一块堆内存。当这样一个字符串对象被复制，不论指针或其所指内存都会被制作出一个复件，这样的字符串展现的就是 深度复制（deep copying)。

△转移底部资源的拥有权

某些情况下你可能希望确保永远只有一个RAII对象，指向一个未加工资源（raw resource），即使 RAII 对象被复制依然如此。此时资源的拥有权会从 被复制物 转移到 目标物。就像第13个条款所述，这是auto_ptr奉行的复制意义。

Copying函数有可能被编译器自己自动创建出来，因此除非编译器所生成版本做了你想做的事，否则你需要自己编写它们。

3.请记住：

★ 复制RAII对象必须一并复制它所管理的资源，所以资源的copying行为决定RAII对象的copying行为

★ 普遍而常见的RAII 类 copying 行为是：抑制 copying 、 施行引用计数法（reference counting)。不过其他行为也都可能被实现。

 

***************************************转载请注明出处：http://blog.csdn.net/lttree********************************************