zoukankan      html  css  js  c++  java
  • Effective C++ —— 定制new和delete(八)

      STL容器所使用的heap内存是由容器所拥有的分配器对象管理,不是被new和delete直接管理。本章并不讨论STL分配器。

    条款49 : 了解new-handler的行为

       当operator new 抛出异常以反映一个未获满足的内存需求之前,它会先调用一个客户指定的错误处理函数,一个所谓的new-handler。可以调用一个声明于<new>的一个标准程序库函数set_new_handler来指定这个函数,set_new_handler的参数是个指针,指向operator new 无法分配足够内存时该调用的函数。其返回值也是个指针,指向set_new_handler被调用前正在执行(但马上就要被替换)的那个new-handler函数。(存储传入指针,返回先前指针)。如下:

    namespace std
    {
        // new_handler 是个typedef
        typedef void (*new_handler) ();
        // throw 表示该函数不抛出任何异常
        new_handler set_new_handler(new_handler p) throw();
    }
    
    // 如下调用
    void outOfMem()
    {
        std::cerr << "Unable to satisfy request for memory 
    ";
        std::abort();
    }
    
    int main()
    {
        std::set_new_handler(outOfMem);
        int* pBigDataArray = new int[100000000L];
        ...
    }

      注意:当operator new 无法满足内存申请时,它会不断调用new_handler函数,直到找到足够内存。引起反复调用的代码显示于条款51。一个设计良好的new_handler函数必须做以下事情:

      (1)让更多内存可被使用。

      (2)安装另一个new-handler。

      (3)卸除new-handler。也就是将null指针传给set_new_handler。一旦没有安装任何new-handler,operator new 会在内存分配不成功时抛出异常。

      (4)抛出bad_alloc(或派生自bad_alloc)的异常。

      (5)不返回,通常调用abort 或 exit。

       C++并不支持class专属之new-handlers,但其实也不需要。你也可以自己实现出这种行为:只需令每一个class提供自己的set_new_handler和operator new即可。

    // 资源管理类(RAII),在构造过程中获得一笔资源,并在析构过程中释还
    class NewHandlerHolder
    {
        public:
            explicit NewHandlerHolder(std::new_handler nh)
                : handler(nh) { }       // 构造,获得资源
            ~NewHandlerHolder()
            { std::set_new_handler(handler); }  // 析构,释还资源
        private:
            std::new_handler handler;    // 记录资源
            NewHandlerHolder(const NewHandlerHolder&);
            NewHandlerHolder& operator=(const NewHandlerHolder&);
    };
    
    template<typename T>
    // "mixin"风格的base class,这种class用来允许derived class 继承单一特定能力
    // 本例中是:设定class专属之new-handler的能力
    class NewHandlerSupport   
    {
        public:
            static std::new_handler set_new_handler(std::new_handler p) throw();
            static void* operator new(std::size_t size) throw(std::bad_alloc);
            ...
        private:
            static std::new_handler currentHandler;
    };
    
    template<typename T>
    std::new_handler
    NewHandlerSupport<T>::set_new_handler(std::new_handler p) throw()
    {
        std::new_handler oldHander = currentHandler;
        currentHandler = p;
        return oldHander;
    }
    
    template<typename T>
    void* NewHandlerSupport<T>::operator new(std::size_t size) throw(std::bad_alloc)
    {
        NewHandlerHolder h(std::set_new_handler(currentHandler));  // 资源管理类记录原来的new_handler
        // 如果成功执行,返回新分配内存块指针;并恢复上面资源管理类记录的new_handler;
        // 如果执行失败,抛出一个bad_allo异常,恢复上面资源管理类记录的new_handler,传播异常
        return ::operator new(size);
    }
    
    
    // static 成员必须在class 定义式之外被定义(除非它们是const 而且是整数型,条款02)
    // 以下语句将每一个currentHandler初始化为null
    template<typename T>
    std::new_handler NewHandlerSupport<T>::currentHandler = 0;
    //有了这个class template,为Widget添加set_new_handler支持能力就轻而易举了:
    // 只要令Widget继承自NewHandlerSupport<Widget>就好,如下:
    class Widget : public NewHandlerSupport<Widget>
    {
        ...     // 和先前一样,不必声明set_new_handler 或 operator new
    };

      (1)上面NewHandlerSupport template从未使用其类型参数T,实际上T的确不需被使用。我们只是希望,继承自己NewHandlerSupport的每一个class ,拥有实体互异的NewHandlerSupport复件(更明确地说是其static成员变量currentHandler)。类型参数T只是用来区分不同的derived class。Template机制会自动为每一个T(NewHandlerSupport赖以具现化的根据)生成一份currentHandler。(2)至于Widget继承自一个模板化的base class,而后者又以Widget作为类型参数,这只是“怪异的循环模板模式”(curiously recurring template pattern;CRTP)。

      很多C++程序时在编译器开始支持新修规范(新规范的operator new 抛出bad_alloc异常)前写出来的,传统的operator new是“分配失败便返回null”行为。这个形式被称为“nothrow”形式。如下:

    class Widget { ... };
    Widget* pw1 = new Widget;     // 如果分配失败,抛出bad_alloc
    if (pw1 == 0) ...         // 这个测试一定失败
    Widget* pw2 = new (std::nothrow) Widget;    // 如果分配Widget失败,返回0
    if (pw2 == 0) ... // 这个测试可能成功

      Nothrow new 对异常的强制保证性并不高。要知道,表达式“new (std::nothrow) Widget”发生两件事,第一,nothrow 版的operator new被调用,用以分配足够内存给Widget对象。如果分配失败便返回null指针,一如文档所言。如果分配成功,接下来Widget构造函数会被调用,而在那一点上所有的筹码便都耗尽,因为Widget构造函数可以做它想做的任何事。它有可能又new一些内存,而没人可以强迫它再次使用nothrow new。

    故而:

      1. set_new_handler允许客户指定一个函数,在内存分配无法获得满足时被调用。

      2. Nothrow new 是一个颇为局限的工具,因为它只适用于内存分配;后继的构造函数调用还是可能抛出异常。

    条款50: 了解new和delete的合理替换时机

       首先,之所以会有人想要替换编译器提供的operator new 或 operator delete,下面是三个常见理由:

      (1)用来检测运用上的错误。

      (2)为了强化效能。定制版性能性能通常会胜过缺省版本。

      (3)为了收集使用上的统计数据。定制版可以帮助我们收集动态内存的大小、分布、寿命、分配次序、是否随时间改变等等各种状态。

      定制一个operator new 十分简单。举个例子,下面是个快速发展得出的初阶段global operator new,促进并协助检测“overruns”(写入点在分配区块尾端之后)或“underruns”(写入点在分配区块起点之前)。有待完善:

    static const int signature = 0xDEADBEEF;
    typedef unsigned char Byte;
    // 这段代码还有若干小错误
    void* operator new (std::size_t size) throw(std::bad_alloc) 
    {
        using namespace std;
        size_t realSize = size + 2 * sizeof(int);  // 增加大小,使能够塞入两个signatures
    
        void* pMem = malloc(realSize);   // 调用malloc取得内存
        if(!pMem) throw bad_alloc();
    
        // 将signature写入内存的最前段落和最后段落
        *(static_cast<int*>(pMem)) = signature;
        *(reinterpret_cast<int*>(static_cast<Byte*>(pMem)
                + realSize - sizeof(int))) = signature;
    
        // 返回指针,指向恰位于第一个signature之后的内存位置
        return static_cast<Byte*>(pMem) + sizeof(int);
    }

      这个operator new 的缺点主要在于它疏忽了身为这个特殊函数所应该具备的“坚持C++规矩”的态度。举个例子,条款51说所有operator news 都应该内含一个循环,反复调用某个new-handling函数,这里却没有。现在,我们先把目光集中在另一个主题:齐位

      许多计算机体系结构要求特定的类型必须放在特定的内存地址上。例如它可能会要求指针的地址必须是4倍数或doubles的地址必须是8倍数。如果没有奉行这个约束条件,可能导致运行期硬件异常。有些体系则宣称如果齐位条件满足便提供较佳效率。在我们这个主题中,齐位意义重大,因为C++要求所有operator news返回的指针都有适当的对齐(取决于数据类型)。malloc就是在这样的要求下工作,所以令operator new返回一个得自malloc的指针是安全的。然而上述operator new 中我并未返回一个得自malloc的指针,而是返回一个得自malloc且偏移一个int大小的指针。没人能够保证它的安全!像齐位这一类技术细节,正可以在那种“因其他纷扰因素而被程序员不断抛出异常”的内存管理器中区分出专业质量的管理器。写一个总是能够运作的内存管理器并不难,难的是它能够优良地运作。

      很多时候没有必要编写自己的内存管理器。某些编译器已经在它们的内存管理函数中切换至调试状态和志记状态;许多平台上已有商业产品可以替代编译器自带的内存管理器;另一个选择是开发源码领域中的内存管理器。Boost程序库(条款55)的Pool就是这样一个分配器。

      本条款主题是,了解何时可在“全局性的”或“class专属的”基础上合理替换缺省的new 和 delete 。下面是一些摘要:

      (1)为了检测运用错误。

      (2)为了收集动态分配内存之使用统计信息。

      (3)为了增加分配和归还速度。

      (4)为了降低缺省内存管理器带来的空间额外开销。

      (5)为了弥补缺省分配器中的非最佳齐位。

      (6)为了将相关对象成簇集中。

      (7)为了获得非传统的行为。

    故而:

      有许多理由需要写个自定的new 和 delete ,包括改善效能、对heap运用错误进行调试、收集heap使用信息。

    条款51: 编写new和delete时需固守常规

       让我们从operator new开始。实现一致性operator new 必得返回正确的值,内存不足时必得调用new-handling函数(条款49),必须有对付零内存需求的准备,还需避免不慎掩盖正常形式的new——虽然这比较偏近class的接口要求而非实现要求。正常形式的new描述于条款52。

      operator new 的返回值十分单纯。如果它有能力提供客户申请的内存,就返回一个指针指向那块内存。如果没有那个能力,就遵循条款49描述的规则,并抛出一个bad_alloc异常。(其实也不是非常单纯,因为operator new 实际上不只一次尝试分配内存(其内含一个无穷循环),并在每次失败后调用new-handling 函数。这里假设new-handling函数也许能够做某些动作将某些内存释放出来。只有当指向new-handling函数的指针是null,operator new 才会抛出异常)。

      下面是个non-member operator new 伪码:

    void* operator new (std::size_t size) throw(std::bad_alloc)
    {
        using namespace std;
        if (size == 0)
        {    
            // 简单、合法、可行
            size = 1;     // 处理0-byte申请,将它视为1-byte申请
        }
        while(true)
        { 
            // 尝试分配size bytes;
            if (分配成功)
                return (一个指针,指向分配得来的内存);
            // 分配失败;找出目前的new-handling函数
            // 很不幸,我们没有任何部分可以直接取得new-handling函数指针
            // 所以必须调用set_new_handler找出它来。拙劣,但有效。
            new_handler globalHandler = set_new_handler(0);
            set_new_handler(globalHandler);
    
            if (globalHandler) (*globalHandler) ();
            else throw std::bad_alloc();
        }
    }

      条款49谈到operator new 内含一个无穷循环,而上述伪码明白表明出这个循环:“while(true)"就是那个无穷循环。退出此循环的唯一办法是:内存被成功分配或new-handling函数做了一件描述于条款49的事情:让更多内存可用、安装另一个new-handler、卸载new-handler、抛出bad_alloc异常(或其派生物),或是承认失败而直接return。现在,对于new-handler为什么必须做出其中某些事你应该很清楚了。如果不那么做,operator new 内的while 循环永远不会结束。

      如果operator new作为一个成员函数,当被derived class 继承便会导致有趣的复杂度。然而,正如条款50所言,写出定制型内存管理器的一个最常见理由是为针对某特定class的对象分配行为提供最优化,却不是为了该class的任何derived classes。其行为很典型地只为大小刚好为sizeof(class)的对象而设计。如下:

    class Base
    {
        public:
            static void* operator new(std::size_t size) throw(std::bad_alloc);
            ...
    };
    class Derived : public Base      // 假设Derived 未声明 operator new
    { ... };
    Derived* p = new Derived;        // 这里调用Base::operator new 
    
    // 如果Base class专属的operator new 并非被设计用来对付上述情况
    // (实际上往往如此),处理此情势的最佳做法是将"内存申请量错误"
    // 的调用行为改采标准operator new,如下
    void* Base::operator new(std::size_t size) throw(std::bad_alloc)
    {
        // 非附属(独立式)对象必须有非零大小,条款39,
        // 所以如果size == 0; 这份申请会转交到 ::operator new手上
        if (size != sizeof(Base))       // 如果不是Base对象,大小错误
            return ::operator new(size);  // 令标准的operator new 起而处理。
        ...          // 否则在这里处理
    }

      这就是撰写operator new时你需要奉行的规矩。operator delete情况更简单,你需要记住的唯一事情就是C++保证“删除null指针永远安全”,所以你必须兑现这项保证。如下:

    // 非成员函数
    void operator delete(void* rawMemory) throw()
    {
        if (rawMemory == 0) return ;        // 如果将被删除的是个null指针,那就什么都不做
    
        // 现在,归还rawMemory所指内存;
    }
    
    // 成员函数
    void operator delete(void* rawMemory) throw()
    {
        if (rawMemory == 0) return ;        // 如果将被删除的是个null指针,那就什么都不做
        // member版本,需要多加一个动作检查删除数量。
        // 万一你的class专属的operator new将大小有误的分配行为转交给
        // ::operator new执行,你也必须将大小有误的删除行为转交给::operator delete执行
        if (size != sizeof(Base))
        {
            ::operator delete(rawMemory);    // 如果大小错误,令标准版operator delete 处理此一申请
            return ;
        }
        // 现在,归还rawMemory所指内存;
        return;
    }

      有趣的是,如果即将被删除的对象派生自某个base class 而后者欠缺virtual析构函数,那么C++传给operator delete 的size_t数值可能不正确。这是“让你的base classes拥有virtual析构函数”的一个够好的理由。条款07提供过一个更好的理由(“局部销毁”)。

    故而:

      1. operator new 应该内含一个无穷循环,并在其中尝试分配内存,如果它无法满足内存需求,就该调用new-handler。它也应该有能力处理0 bytes申请。class专属版本则还应该处理“比正确大小更大的(错误)申请”。

      2. operator delete 应该在收到null指针时不做任何事。class专属版本则还应该处理“比正确大小更大的(错误)申请”。

    条款52: 写了placement new 也要写 placement delete

       回忆条款16,17,当你写一个new表达式像这样:

    Widget* pw = new Widget;

      共有两个函数被调用:一个是用以分配内存的operator new,一个是Widget的default构造函数。假设其中第一个函数调用成功,第二个函数却抛出异常。既然那样,步骤一的内存分配所得必须取消并恢复旧观,否则会造成内存泄漏。但在这个时候,客户没有能力归还内存,因为如果Widget构造函数抛出异常,pw尚未被赋值,客户手上也就没有指针指向该被归还的内存。取消步骤一并恢复旧观的责任因此落到C++运行期系统身上。这对于拥有正常签名式的new和delete来说并不是问题,但如果是使用了带有附带参数的operator new,“究竟哪一个delete伴随这个new”的问题便浮现了。

      首先先讨论若干术语。如果operator new 接受的参数除了一定会有的那个size_t 之外还有其他,这便是个所谓的placement new。在众多placement new版本中特别有用的一个是“接受一个指针指向对象该被构造之处”,那样的operator new 形如:

    void* operator new(std::size_t, void* pMemory) throw(); // placement new

      这个版本的new已被纳入C++标准程序库,你只要#include <new> 就可以取用它(一个特定位置上的new)。现在考虑以下代码:

    // 调用operator new 并传递cerr为其ostream实参;
    // 这个动作会在Widget构造函数抛出异常时泄漏内存
    Widget* pw = new (std::cerr) Widget;  

      再说一次,如果内存分配成功,而Widget构造函数抛出异常,运行期系统有责任取消operator new 的分配并恢复旧观。然而运行期系统无法知道真正被调用的那个operator new如何运作,因此它无法取消分配并恢复旧观,所以上述做法行不通。取而代之的是,运行期系统寻找“参数个数和类型都与operator new 相同”的某个operator delete。如果找到,那就是它的调用对象。既然这里的operator new 接受类型为ostream& 的额外实参,所以对应的operator delete 就应该是:

    void operator delete(void*, std::ostream&) throw();

      类似于new 的placement版本,operator delete 如果接受额外参数,便称为placement deletes。如果Widget没有声明placement版本的operator delete,那么运行期系统不知道如何取消并恢复原先对placement new的调用。加上placement delete 之后,代码如下:

    class Widget
    {
        public:
            ...
            static void* operator new(std::size_t size, std::ostream& logStream) throw(std::bad_aloc);  // placement new
            static void operator delete(void* pMemory) throw();   // normal delete
            static void operator delete(void* pMemory, std::ostream& logStream) throw();   // placement delete
            ...
    };
    
    // 以下调用
    Widget* pw = new (std::cerr) Widget;      // 一如以往,但这次不再泄漏
    // 如果上面语句引发Widget构造函数抛出异常,对应的placement delete 会被自动调用,让Widget有机会确保不泄漏任何内存
    // 然而,如果没有抛出异常(通常如此)客户代码有个对应的delete
    delete pw;     // 调用正常的operator delete

      如果Widget构造函数没有抛出异常(通常如此),那么就如上一行注释所言,调用的是正常形式的operator delete,而非其placement 版本。placement delete只有在“伴随placement new 调用而触发的构造函数”出现异常时才会被调用。对着一个指针(例如上述的pw)施行delete绝不会导致调用placement delete。绝对不会。这意味如果要对所有与placement new 相关的内存写了宣战,我们必须同时提供一个正常的operator delete (用于构造期间无任何异常被抛出)和一个placement delete版本(用于构造期间有异常被抛出)。后者的额外参数必须和operator new 一样。

      注意,由于成员函数的名称会遮掩其外围作用域中的相同名称(条款33),你必须小心避免让class 专属的news 遮掩客户期望的其他news(包括正常版本)。如class news 遮掩正常形式的new;或者derived classes中的operator news遮掩base class news。解决方法是,可以建立一个base class ,内含所有正常形式的new和delete

    class StrandardNewDeleteForms
    {
        public:
            // normal new/delete
            static void* operator new(std::size_t size) throw(std::bad_alloc)
            { return ::operator new(size); }
            static void operator delete(void* pMemory) throw()
            { ::operator delete(pMemory); }
    
            // placement new/delete
            static void* operator new(std::size_t size, void* ptr) throw()
            { return ::operator new(size, ptr); }
            static void operator delete(void* pMemory, void* ptr) throw()
            { ::operator delete(pMemory, ptr); }
    
            // nothow new/delete
            static void* operator new(std::size_t size, const std::nothrow_t& nt) throw()
            { return ::operator new(size, nt); }
            static void operator delete(void* pMemory, const std::nothrow_t&) throw()
            { ::operator delete(pMemory); }
    };
    
    // 凡是想以自定形式扩充标准形式的客户,可利用继承机制及using声明式(条款33)取得标准形式
    class Widget : public StrandardNewDeleteForms
    {
        public:
            using StrandardNewDeleteForms::operator new;      // 让基类new形式可见
            using StrandardNewDeleteForms::operator delete;
    
            static void* operator new(std::size_t size, std::ostream& logStream)     // 自定placement new
                    throw(std::bad_alloc);
            static void operator delete(void* pMemory, std::ostream& logStream)   // 添加一个对应placement delete
                    throw();
            ...
    };

    故而:
      1. 当你写一个placement operator new ,请确定也写出了对应的placement operator delete。如果没有这样做,你的程序可能会发生隐微而时断时续的内存泄漏。

      2. 当你声明placement new 和 placement delete,请确定不要无意识(非故意)地遮掩了它们的正常版本。

  • 相关阅读:
    RSA使用
    C#获取主机信息
    NSIS打包软件使用
    C#获取局域网主机
    C#实现Web链接启动应用程序
    4.布局介绍
    Server Sql 多表查询、子查询和分页
    C# File类常用方法
    Vue 使用技巧手记
    前端面试题手记
  • 原文地址:https://www.cnblogs.com/yyxt/p/4823334.html
Copyright © 2011-2022 走看看