C++之资源管理

        所谓资源就是一旦使用完，就必须将其归还给系统，否则就有你好果子吃。在C++总，常用的资源包括动态分配内存、文件描述符、互斥锁、UI中的字型和笔刷、数据库连接，网络socket等。接下来本文介绍几种管理资源的方式，以解决资源泄露或回收问题。
一、以对象管理资源
         假设我们使用一个用来朔模投资行为的程序库，其中各式各样的投资类型继承自一个root class Investment：
        class Investment {...};        //投资类型继承体系中的root class
        进一步假设，这个程序库通过一个工厂函数供应我们某个特定的Investment对象：
        Investment* createInvestment();        
        上面函数返回一个指针，指向Investment继承体系内的动态分配对象，调用者有责任删除它。假设有个函数f履行了这个责任：
        void f()
        {
                Investment* pInv = createInvestment();        //调用工厂函数
                ...
                delete pInv;                                                //释放pInv所指对象
        }
        咋一看上面天衣无缝，函数f能够自动删除它从createInvestment获得的投资对象，但是事实上危机重重：
        （1）由于疏忽或者后期接收者维护代码导致“...”区域内的一个过早的return语句或goto语句。
        （2）“...”区域内的语句抛出异常。
        上面的任意情况发生，都会导致因无法执行到delete语句而内存泄露。事实上，函数f中将资源的管理依赖于人治，所以悲剧地发生只是时间问题。
        为了解决如上问题，需要将返回的资源放进对象内，以对象来管理资源，当控制流离开f，该对象的析构函数会自动释放那些资源。
1、auto_ptr
        许多资源被动态分配于堆上而后被用于单一区块或函数内，资源应该在控制流离开这个区块或函数时被释放，标准程序库提供的auto_ptr正是针对这种形式而设计的特制产品。
        auto_ptr是一个“类指针（pointer-like）对象”，也就是所谓的智能指针，其析构函数自动对其所指对象调用delete。下面示范如何使用auto_ptr以避免函数f潜在的资源泄露可能性：
        void f()
        {
                std::auto_ptr pInv(createInvestment());
                ...
        }
        函数f中调用工厂函数产生投资对象，并将对象由auto_ptr管理，然后一如既往地使用pInv，在控制流离开函数f时，由auto_ptr的析构函数自动删除pInv。
        上面代码中createInvestment返回的资源被当做其管理者auto_ptr的初值，这种方式被称为“资源获得时机便是初始化时机”（Resource Acquisition Is Initialization, RAII）。
        需要注意的是：如果通过copy构造函数或copy assignment操作符复制auto_ptr，则其会变成NULL，而复制所得的指针将取得资源的唯一拥有权，也就是只能有一个auto_ptr对象管理资源，比如：
        std::auto_ptr pInv1(createInvestment());     //pInv1指向createInvestment返回物
        std::auto_ptr pInv2(createInvestment());     //pInv2指向对象，而pInv1被设为NULL
        pInv1 = pInv2;                                                              //现在pInv1指向对象，而pInv2被设为NULL
        受auto_ptr管理的资源必须绝对没有一个以上的auto_ptr同时指向它，这意味着auto_ptr并非管理动态分配资源的神兵利器，比如STL容器就要求其元素发挥“正常的”复制行为，因此就用不上auto_ptr。
2、shared_ptr
        auto_ptr的替代方案是“引用计数型智能指针”（referece-counting smart pointer, RCSP）。所谓RCSP也是个智能指针，持续追踪共有多少对象指向某笔资源，并在无人指向它时自动删除该资源。RCSP提供的行为类似垃圾回收（garbage collection），不同的是RCSP无法打破环状引用（cycles of references，比如：两个其实已经没被使用的对象彼此互指，因而好像还处在“被使用”状态）。
        TR1的tr1::shared_ptr就是一个RCSP，所以函数f的又一版本来了：
        void f()
        {
                std::tr1::shared_ptr pInv(createInvestment());    //在离开函数时，由shared_ptr析构函数自动删除pInv
                ...
        }
        这与auto_ptr版本基本一致，但shared_ptr的复制行为正常多了：
        void f()
        {
                std::tr1::shared_ptr pInv1(createInvestment);        //pInv1指向createInvestment返回物
                std::tr1::shared_ptr pInv2(pInv1);                         //pInv2和pInv2指向同一个对象
                pInv1 = pInv2;                                                                        //同上，无任何改变
                ...
        }
        在函数f控制流结束时，pInv1和pInv2被销毁，其所指对象也就被自动销毁。由于tr1::shared_ptr的复制行为“一如预期”，它可被用于STL容器以及其它“auto_ptr之非正统复制行为并不适用”的语境上。
        但是auto_ptr和tr1::shared_ptr两者都在其析构函数内做delete而不是delete[]，这意味其不能用于动态分配的数组，而boost::scoped_array和boost::shared_array class则能提供这种行为。

二、资源管理类中小心coping行为
        我们在使用C API函数处理类型为Mutex的互斥量对象（mutex object）时，一般会提供lock和unlock函数：
        void lock(Mutex* pm);        //锁定pm所指的互斥量
        void unlokc(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;                   //定义你需要的互斥量     
        ...                             
        {                              //建立一个区块用来定义critical section
            Lock ml(&m);         //锁定互斥量
            ...                        //执行critical section内的操作
        }                             //在区块最末尾，自动解除互斥量锁定
        上面代码看似很完美，但是如果Lock对象被复制，又将如何呢？
        Lock m11(&m);         //锁定m
        Lock m12(ml1);         //将ml1复制到ml2身上，会发送什么呢？
        一般为了防止复制RAII对象带来的副作用，会采取禁止复制的方式，也就是将coping操作声明为private，包括拷贝构造函数和赋值操作符。        
            
三、承诺使用new和delete是要采取相同型式
        成对使用new和delete时要采用相同型式，比如：如果你在new表达式中使用[]，必须在相应的delete表达式中也使用[]，否则的话其结果未定义（在delete时可能会导致太少的析构函数被调用）；如果你在new表达式中不使用[]，一定不要在相应的delete表达式中使用[]。
        为什么会如此，因为在new单一对象和对象数组时内存布局会不同，可能的布局如下：
        单一对象 object
        对象数组 n | object |object | ...
        其中，n表示数组大小，当然不同的编译器做法不尽相同。

四、独立语句将newed对象植入智能指针
        假设我们有个函数用来揭示处理程序的优先权，另一个函数用来在某动态分配所得的widget上进行某些带优先权的处理：
        int priority();
        void processwidget(std::tr1::shared_ptr pw, int priority);
        假设我们如此调用：
        processwidget(std::tr1::shared_ptr(new widget), priority());
        上面代码看似用对象管理资源，但是事实上确还是有可能泄露资源。因为编译器在产出一个processwidget调用码之前，会先核算即将被传递的各个实参，并做如下几件事情：
        （1）调用函数priority
        （2）执行new widget
        （3）调用tr1::shared_ptr构造函数
        但C++编译器不一定会按照上面顺序来生成代码，最终可能的操作序列会是：
        （1）执行new widget
        （2）调用priority函数
        （3）调用tr1::shared_ptr构造函数
        好吧，问题来了，如果在调用priority函数时产生异常，则new widget返回的指针会被遗失，因为其尚未被置入tr1::shared_ptr内，从而引发资源泄露。
        避免产生这种问题的方法很简单：使用分离语句，分别写出（1）创建widget；（2）将它置入一个智能指针内，然后将智能指针传给processwidget函数：
        std::tr1::shared_ptr pw(new widget);        
        processwidget(pw, priority());
        以独立语句将newed对象存储于（置入）智能指针内，如果不这样做，一旦异常抛出，就有可能导致难以察觉的资源泄露。