C 箴言：谨慎考虑资源管理类的拷贝行为

　　在上一篇文章中介绍了作为资源管理类支柱的 Resource Acquisition Is Initialization (RAII) 原则，并描述了 auto_ptr 和 tr1::shared_ptr 在基于堆的资源上运用这一原则的表现。并非任何的资源都是基于堆的，然而，对于这样的资源，像 auto_ptr 和 tr1::shared_ptr 这样的智能指针通常就不像 resource handlers（资源管理者）那样合适。在这种情况下，有时，您可能要根据您自己的需要去创建您自己的资源管理类。

　　例如，假设您使用 C API 提供的 lock 和 unlock 函数去操纵 Mutex 类型的互斥体对象：

void lock(Mutex *pm); // lock mutex pointed to by pm

void unlock(Mutex *pm); // unlock the mutex

　　为了确保您从不会忘记解锁一个被您加了锁的 Mutex，您希望创建一个类来管理锁。RAII 原则规定了这样一个类的基本结构，通过构造函数获取资源并通过析构函数释放他：

class Lock {
　public:
　　explicit Lock(Mutex *pm)
　　: mutexPtr(pm)
　　{ lock(mutexPtr); } // acquire resource
　
　　~Lock() { unlock(mutexPtr); } // release resource

　private:
　　Mutex *mutexPtr;
};

　　客户按照 RAII 风格的惯例来使用 Lock：

Mutex m; // define the mutex you need to use
...
{ // create block to define critical section
　Lock ml(&m); // lock the mutex
　... // perform critical section operations

} // automatically unlock mutex at end
// of block

　　这没什么问题，但是假如一个 Lock 对象被拷贝应该发生什么？

Lock ml1(&m); // lock m

Lock ml2(ml1); // copy ml1 to ml2-what should
// happen here?

　　这是个更一般问题的特定实例，每一个 RAII 类的作者都要面临这样的问题：当一个 RAII 对象被拷贝的时候应该发生什么？大多数情况下，您能够从下面各种可能性中挑选一个：

　　禁止拷贝。在很多情况下，允许 RAII 被拷贝是没有意义的。这对于像 Lock 这样类很可能是正确的，因为同步的基本要素的“副本”很少有什么意义。当拷贝对一个 RAII 类没有什么意义的时候，您应该禁止他。Item 6 解释了如何做到这一点。声明拷贝操作为私有。对于 Lock，看起来也许像这样：

class Lock: private Uncopyable { // prohibit copying - see
public: // Item 6
... // as before
};

　　对底层的资源引用计数。有时人们需要的是保持一个资源直到最后一个使用他的对象被销毁。在这种情况下，拷贝一个 RAII 对象应该增加引用这一资源的对象的数目。这也就是使用 tr1::shared_ptr 时“拷贝”的含意。

　　通常，RAII 类只需要包含一个 tr1::shared_ptr 数据成员就能够实现引用计数的拷贝行为。例如，假如 Lock 要使用引用计数，他可能要将 mutexPtr 的类型从 Mutex* 改变为 tr1::shared_ptr<Mutex>。不幸的是，tr1::shared_ptr 的缺省行为是当他所指向的东西的引用计数变为 0 的时候将他删除，但这不是我们要的。当我们使用 Mutex 完毕后，我们想要将他解锁，而不是将他删除。

　　幸运的是，tr1::shared_ptr 允许一个 "deleter" 规范——当引用计数变为 0 时调用的一个函数或函数对象。（这一功能是 auto_ptr 所没有的，auto_ptr 总是删除他的指针。）deleter 是 tr1::shared_ptr 的构造函数的可选的第二个参数，所以，代码看起来就像这样：

class Lock {
public:
　explicit Lock(Mutex *pm) // init shared_ptr with the Mutex
　: mutexPtr(pm, unlock) // to point to and the unlock func
　{ // as the deleter

　　lock(mutexPtr.get()); // see Item 15 for info on "get"
　}
private:
　std::tr1::shared_ptr<Mutex> mutexPtr; // use shared_ptr
}; // instead of raw pointer

　　在这个例子中，注意 Lock 类是如何不再声明一个析构函数的。那是因为他不再需要。Item 5 解释了一个类的析构函数（无论他是编译器生成还是用户定义）会自动调用这个类的非静态（non-static）数据成员的析构函数。在本例中，就是 mutexPtr。但是，当互斥体的引用计数变为 0 时，mutexPtr 的析构函数会自动调用的是 tr1::shared_ptr 的 deleter ——在此就是 unlock。（看过这个类的源代码的人多半意识到需要增加一条注释表明您并非忘记了析构，而只是依赖编译器生成的缺省行为。）

　　拷贝底层的资源。有时就像您所希望的您能够拥有一个资源的多个副本，唯一的前提是您需要一个资源管理类确保当您使用完他之后，每一副本都会被释放。在这种情况下，拷贝一个资源管理对象也要同时拷贝被他隐藏的资源。也就是说，拷贝一个资源管理类需要完成一次“深层拷贝”。

　　某些标准 string 类型的实现是由堆内存的指针组成，堆内存中存储着组成那个 string 的字符。这样的字符串对象包含指向堆内存的指针。当一个 string 对象被拷贝，这个副本应该由那个指针和他所指向的内存组成。这样的 strings 表现为深层拷贝。

　　传递底层资源的任何权。在某些特别场合，您可能希望确保只有一个 RAII 对象引用一个未加工的资源，而当这个 RAII 对象被拷贝的时候，资源的任何权从被拷贝的对象传递到拷贝对象。就像上一篇文章所说明的，这就是使用 auto_ptr 时“拷贝”的含意。

　　拷贝函数（copying functions）（拷贝构造函数和拷贝赋值运算符）可能是由编译器生成的，所以除非编译器生成的版本所做的事正是您所要的，您应该自己编写他们。在某些情况下，您也要支持这些函数的泛型化版本。

　　Things to Remember

　　·拷贝一个 RAII 对象必须拷贝他所管理的资源，所以资源的拷贝行为决定了 RAII 对象的拷贝行为。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有