微网站做的比较好的,wordpress增加定位锚点,我国网络营销方式,鹤壁高端网站建设条款13导入这样的观念:“资源取得时机便是初始化时机”(Resource Acquisitionls Initialization; RAII)#xff0c;并以此作为“资源管理类”的脊柱#xff0c;也描述了auto_ ptr和tr1::shared ptr如何将这个观念表现在 heap-based资源上。然而并非所有资源都是heap-based RAII)并以此作为“资源管理类”的脊柱也描述了auto_ ptr和tr1::shared ptr如何将这个观念表现在 heap-based资源上。然而并非所有资源都是heap-based对那种资源而言像auto_ptr和 tr1 : :shared_ptr这样的智能指针往往不适合作为资源掌管者(resource handlers。既然如此有可能偶而你会发现你需要建立自己的资源管理类。
例如假设我们使用C API函数处理类型为Mutex的互斥器对象( mutexobjects共有lock和unlock两函数可用:
void lock(Mutex* pm); // 锁定pm所指的互斥器
void unlock(Mutex* pm); // 将互斥器解除锁定为确保绝不会忘记将一个被锁住的 Mutex解锁你可能会希望建立一个class用来管理机锁。这样的class 的基本结构由RAII守则支配也就是“资源在构造期间获得在析构期间释放”:
class Lock {
public:explicit Lock(Mutex* pm):mutexPtr(pm){lock(mutexPtr); // 获得资源}~Lock() {unlock(mutexPtr); // 释放资源}private:Mutex* mutexPtr;
};
客户对Lock的用法符合RAII 方式:
Mutex m; // 定义你所需要的互斥器
// ...
{Lock m1(m); // 建立一个区块用来定义关键部分// 锁定互斥器// 执行相关代码
} // 自动解除互斥器锁定这很好但如果Lock对象被复制会发生什么事?
Lock m11(m); // 锁定m
Lock m12(m11); // 将m11复制到m12上会发生什么这是某个一般化问题的特定例子。那个一般化问题是每位RAII class作者一定需要面对的:“当一个RAII对象被复制会发生什么事?”大多数时候你会选择以下两种可能:
禁止复制。许多时候允许RAII对象被复制并不合理。对一个像Lock这样的class这是有可能的因为很少能够合理拥有“同步化基础器物”( synchronizationprimitives的复件副本)。如果复制动作对RAIl class并不合理你便应该禁止之。条款6告诉你怎么做:将copying操作声明为private。对Lock 而言看起来是这样:
class Lock: private Uncopyable { // 禁止复制
public:// ...
};对底层资源祭出“引用计数法”(reference-count。有时候我们希望保有资源直到它的最后一个使用者某对象被销毁。这种情况下复制RAII对象时应该将资源的“被引用数”递增。tr1 : :shared_ ptr便是如此。
通常只要内含一个tr1::shared _ptr成员变量RAII classes 便可实现出reference-counting copying行为。如果前述的 Lock打算使用reference counting,它可以改变mutexPtr的类型将它从Mutex*改为tr1::shared_ ptrMutex。然而很不幸tr1::shared ptr的缺省行为是“当引用次数为О时删除其所指物”那不是我们所要的行为。当我们用上一个Mutex,我们想要做的释放动作是解除锁定而非删除。
幸运的是 tr1::shared_ptr 允许指定所谓的“删除器”(deleter那是一个函数或函数对象function object当引用次数为0时便被调用此机能并不存在于auto_ptr——它总是将其指针删除。删除器对tr1::shared _ptr构造函数而言是可有可无的第二参数所以代码看起来像这样:
class Lock {
public:explicit Lock(Mutex* pm):mutexPtr(pm, unlock){lock(mutexPtr.get());}private:std::tr1::shared_ptrMutex mutexPtr; // 使用shared_ptr代替
};请注意本例的Lock class不再声明析构函数。因为没有必要。条款5说过,class析构函数(无论是编译器生成的,或用户自定的)会自动调用其non-static成员变量本例为mutexPtr)的析构函数。而 mutexPtr的析构函数会在互斥器的引用次数为0时自动调用tr1::shared_ptr的删除器本例为unlock。(当你阅读这个class的原始码或许会感谢其中有条注释指出:你并没有忘记析构你只是倚赖了编译器生成的缺省行为。)
复制底部资源。有时候只要你喜欢可以针对一份资源拥有其任意数量的复件副本。而你需要“资源管理类”的唯一理由是当你不再需要某个复件时确保它被释放。在此情况下复制资源管理对象应该同时也复制其所包覆的资源。也就是说,复制资源管理对象时进行的是“深度拷贝”。 某些标准字符串类型是由“指向heap内存”之指针构成那内存被用来存放字符串的组成字符。这种字符串对象内含一个指针指向一块heap内存。当这样一个字符串对象被复制不论指针或其所指内存都会被制作出一个复件。这样的字符串展现深度复制deep copying行为。转移底部资源的拥有权。某些罕见场合下你可能希望确保永远只有一个RAI对象指向一个未加工资源raw resource即使RAII对象被复制依然如此。此时资源的拥有权会从被复制物转移到目标物。一如条款13所述这是auto_ptr奉行的复制意义。
Coping函数包括copy构造函数和copy assignment操作符有可能被编译器自动创建出来因此除非编译器所生版本做了你想要做的事条款5提过其缺省行为否则你得自己编写它们。某些情况下你或许也想支持这些函数的一般版本这样的版本描述于条款45。
请记住
复制RAII 对象必须一并复制它所管理的资源所以资源的copying行为决定RAII对象的copying行为。普遍而常见的 RAII class copying行为是:抑制copying、施行引用计数法(reference counting。不过其他行为也都可能被实现。
