C++箴言资源管理类的拷贝行为.pdfVIP

C++箴言：资源管理类的拷贝行为 在上一篇文章中介绍了作为资源管理类支柱的 Resource Acquisition Is Initialization (RAII) 原则，并描述了 auto_ptr 和 tr1::shared_ptr 在基于堆的资源上运用这一原则的 表现。并非所有的资源都是基于堆的，然而，对于这样的资源，像 auto_ptr 和 tr1::shared_ptr 这样的智能指针通常就不像 resourcehandlers（资源管理者）那样合适。 在这种情况下，有时，你可能要根据你自己的需要去创建你自己的资源管理类。 例如，假设你使用 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。不幸的是，tr1::shared_ptr 的缺省行为