C/C++编程：小心资源管理类的拷贝行为

曾经终败给现在 2023-01-19 11:57 143阅读 0赞

# 引入 #

我们**常用对象(比如shared\_ptr)来管理资源**，而且资源取得时机就是初始化时机。然而并非所有的资源都是heap-bases，对于这样的资源，类似shared\_ptr这样的智能指针往往不适合作为资源管理者(resource handler)。这种情况下，我们需要建立自己的资源管理类

# 示例 #

假设我们使用C API函数处理类型为Mutex的互斥器对象(mutex object)，共有lock和unlock两函数可用：

void lock(Mutex *pm);   // 锁定pm所指互斥器 
    void unlock(Mutex *pm); // 解锁

为确保绝不对忘记将一个被锁住的Mutex解锁，你可能会希望建立一个类用来管理锁。这样的类的基本结构由RAII守则支配，也即是"资源在构造期间获得，在析构期间释放"：

class Lock{
        
    public:
    	explicit Lock(Mutex *pm) : mutexPtr(pm){
        
    		lock(mutexPtr);   // 获得资源
    	}
    	~Lock(){
        unlock(mutexPtr);};  // 释放资源
    private:
    	Mutex *mutexPtr;
    };

客户的使用方法：

Mutex m;     //定义你需要的互斥器
    {
        
    	Lock m1(&m);  // 上锁
    	... 
    }   // 自动解锁

这当然是对的。但是如果Lock对象被赋值，会发生什么事情？

Lock m1(&m);  //锁定m
    Lock m2(m1);  // 将m1复制到m2，会发生什么事情？

换句话说：**当一个RAII对象被复制，会发生什么事情**？

*  **禁止复制**：

class Lock : private Uncopyable{
        };

*  **对底层资源祭出’引用计数法’**。有时候我们希望保有资源，直到它的最后一个使用者被销毁，这种情况下复制RAII对象时，应该将资源的"被引用数"递增，shared\_ptr就是如此。
    
     *  通常只要内含一个shared\_ptr成员变量，RAII类就可以实现出reference-counting copying行为。如果上面的Lock打算是哟个reference counting，它可以改变mutexPtr的类型，将它从Mutex\*改为shared\_ptr。但是shared\_ptr的缺省行为是"当引用次数为0时删除所指物"，那不是我们要的行为。我们想要的是解锁而不是删除
     *  幸运的是shared\_ptr允许指定"删除器"(deleter)。删除器是一个函数或者函数对象，当引用次数为0时就被调用
     *  注意，下面不需要声明析构函数。**类析构函数(无论是编译器生成的还是用户自定的)会自动调用其non-static成员变量(本例为mutexPtr)的析构函数**。而mutexPtr的析构函数会在互斥器的引用次数为0时自动调用shared\_ptr的删除器。

class Lock {
        
    public:
    	explicit Lock(Mutex *pm)
    		: mutexPtr(pm, unlock){
          // 以Mutex 初始化shared_ptr并以unlock函数为删除器
    		lock(mutexPtr.get());
    	}
    private:
    	std::shared_ptr<Mutex> mutexPtr;
    }

*  **复制底部资源**：有时候，只要你喜欢，可以针对一份资源复制其任意数量的副本。而你需要"资源管理类"的唯一理由是，当你不再需要某个副本时确保它释放。在此情况下复制资源管理对象，应该同时赋值其所包裹的资源。也就是说，复制资源队列对象时，进行的是"深度拷贝"
 *  **转移底部资源的所有权**：此时永远只会有一个RAII对象指向一个资源，auto\_ptr就是这么干的

# 总结 #

*  复制RAII对象时必须一并复制它管理的资源，所以资源的拷贝行为决定了RAII对象的拷贝行为
 *  常见的RAII类拷贝行为是：禁止复制、引用计数法