Effective C++ 条款14

在资源管理器中小心copying行为

上节是对资源的管理说明。有时候我们不能依赖于shared_ptr或者auto_ptr,所以我们须要自己建立一个资源管理类来管理自己的资源。

比如建立一个类来管理Mutex锁。如今使用函数处理类型为Mutex的相互排斥器对象

class Lock{
public:
    explicit Lock(Mutex* mu):mutexPtr(mu)
    {
        lock(mutexPtr);
    }
    ~Lock()
    {
        unlock(mutexPtr);
    }
private:
    Mutex* mutexPtr;
};

void lock(Mutex* mu);//加锁
void unlock(Mutex* mu);//解锁

Mutex m;//定义相互排斥器
……
{
    Lock(&m);
    ……
}

以上代码能够完毕对资源的释放,这里的释放对于mutex来说的真正意义就是解锁。而不是销毁。

然而。以上代码是有问题的,比方运行Lock m2(m1);这句话时。我们须要怎么面对?难道就是两个对象交互的操纵mutex?这样做绝对不行,我们不能确定什么时候m2和m1会被析构,一旦被析构就会导致mutex解锁,mutex一旦解锁就会被别的进程所调用,程序将出现巨大的混乱!

解决上述问题一般有下面几种方式:

1、禁止复制

很多情况下,复制RAII对象并不合理。比如Lock类,这时候便能够禁止复制。仅仅需将coping函数设为私有。条款6有讲述

2、对管理资源使用引用计数法。模仿shared_ptr

3、复制底部资源。这里要是深拷贝

4、转移底层资源的拥有权。

模仿auto_ptr.

作者举出另外一种方式的详细操作。例如以下:

class Lock:private Uncopyable{
public:
    explicit Lock(Mutex* mu):mutexPtr(mu,unlock)//以某个Mutex初始化。unlock作为删除其
    {
        lock(mutexPtr);
    }
private:
    shared_prt<Mutex> mutexPtr;
};

假设上述Lock类使用引用计数器的话,仅仅需把mutexPrt变为类型从Mutex*变为shared就可以。但shared_ptr默认是当引用计数为0时,删除多指向对象,这不是我们想要的,我们想要的是调用unlock函数。幸运的是在shared_ptr中同意指定“删除器”。即引用计数为0时调用的函数。

时间: 2024-10-14 13:27:50

Effective C++ 条款14的相关文章

Effective C++——条款14(第3章)

条款14:    在资源管理类中小心copying行为 Think carefully about copying behavior in resource-managing classes 条款13导入这样的观念:"资源取得时机便是初始化时机"(Resource Acquisition Is Initializaiton,RAII),并以此作为"资源管理类"的脊柱,也描述了auto_ptr和tr1::shared_ptr如何将这个观念表现在heap-based资源

More Effective C++ 条款14 明智运用exception specifications

1. Exception specifications作为函数声明的一部分,用于指出(并不能限制)函数可能会抛出的异常函数.C++规定,一个拥有exception specification的函数指针只能被赋予一个有着相同或更为局限的exception specification的函数地址,因而编译器要保证"在函数指针传递之际检验exception specifications".(但visual studio 2013不支持此项要求) 2. 当函数抛出exception specif

Effective C++ -----条款14: 在资源管理类中小心copying行为

复制RAII对象必须一并复制它所管理的资源,所以资源的copying行为决定RAII对象的copying行为. 普遍而常见的RAII class copying行为是:抑制copying(使用私有继承Uncopyable).施行引用计数法(reference counting)(即std::tr1::shared_ptr,可以自己指定删除器).不过其他行为也都可能被实现.

effective c++ 条款14:在资源管理类中小心拷贝行为

注意: 赋值RAII对象必须一并复制它所管理的资源,所以资源的拷贝行为决定RAII对象的拷贝行为. 普遍而常见的RAII类拷贝行为是:抑制拷贝,实行引用计数法. void lock(Mutex* pm); void unlock(Mutex* pm); class Lock { public: explicit Lock(Mutex* pm) : mutexPtr(pm) { lock(mutexPtr); } ~Lock() { unlock(mutexPtr); } private: Mut

Effective C++:条款14:在资源管理类中小copying行为

(一) 上一条款说的auto_ptr和tr1::share_ptr适合于heap-based的资源,然而并不是所有资源都是heap-based的.换句话说并不是tr1::shared_ptr 和 auto_ptr 永远适合做为资源的管理者.所以有时难免还是需要实现自己的资源管理类型. 假设Mutex类型通过lock和unlock两组函数进行互斥器的锁定和解锁,可能我们希望和auto_ptr一样的行为,在某个智能类型析构时主动调用unlock进行解锁.比如下面的代码: void lock(Mute

Effective C++ 条款13/14 以对象管理资源 || 在资源管理类中小心拷贝行为

三.资源管理       资源就是一旦你使用了它,将来不用的时候必须归还系统.C++中最常用的资源就是动态内存分配.其实,资源还有 文件描述符.互斥器.图形界面中的字形.画刷.数据库连接.socket等. 1.        以对象管理资源       void f() {     investment *plv = createInvestment();     //这里存在很多不定因素,可能造成下面语句无法执行,这就存在资源泄露的可能.     delete plv; }      这里我们

Effective C++ 条款三 尽可能使用const

参考资料:http://blog.csdn.net/bizhu12/article/details/6672723      const的常用用法小结 1.用于定义常量变量,这样这个变量在后面就不可以再被修改     const int val = 90;      val = 100;   错误 2. 保护传参时参数不被修改,如果使用引用传递参数或按地址传递参数给一个函数,在这个函数里这个参数的值若被修改, 则函数外部传进来的变量的值也发生改变,若想保护传进来的变量不被修改,可以使用const

More Effective C++ 条款35 让自己习惯于标准C++ 语言

(由于本书出版于1996年,因此当时的新特性现在来说可能已经习以为常,但现在重新了解反而会起到了解C++变迁的作用) 1. 1990年后C++的重要改变 1). 增加了新的语言特性:RTTI,namespaces,bool,关键词mutable和explicit,enums作为重载函数之自变量所引发的类型晋升转换,以及"在class 定义区内直接为整数型(intergral) const static class members设定初值"的能力. 2). 扩充了Templates的特性

effective c++ 条款4 make sure that objects are initialized before they are used

1 c++ 类的数据成员的初始化发生在构造函数前 class InitialData { public: int data1; int data2; InitialData(int a, int b) { data1 = a: //this is assignment data2 = b; //this is assignment } /* InitialData(int a, int b):data1(a),data2(b) //this is initial {} */ } 2 不同cpp文