• C++ 核心指南之资源管理(中)分配和释放


    C++ 核心指南(C++ Core Guidelines)是由 Bjarne Stroustrup、Herb Sutter 等顶尖 C++ 专家创建的一份 C++ 指南、规则及最佳实践。旨在帮助大家正确、高效地使用“现代 C++”。

    这份指南侧重于接口、资源管理、内存管理、并发等 High-level 主题。遵循这些规则可以最大程度地保证静态类型安全,避免资源泄露及常见的错误,使得程序运行得更快、更好。

    R.alloc: 分配和释放

    • R.10: 避免使用 malloc() / free()
    • R.11: 避免显式调用 new / delete
    • R.12: 显式资源分配的结果应立即给到资源管理对象
    • R.13: 在一条语句中,最多只能有一个显式资源分配
    • R.14: 避免使用 [] 参数,用 span 替代
    • R.15: 分配/释放操作要成对重载

    R.10: 避免使用 malloc() / free()

    malloc() / free() 不支持构造、析构,不要和 new / delete 混用。

    例子

    class Record {
        int id;
        string name;
    };
    
    void use()
    {
        // p1 可能是 nullptr;*p1 未初始化,尤其是其中的 name 不是一个合法的 string 对象
        Record* p1 = static_cast(malloc(sizeof(Record)));
        // 除非抛异常,*p2 默认初始化
        auto p2 = new Record;
        // p3 可能是 nullptr;如果不为空,*p3 默认初始化
        auto p3 = new(nothrow) Record;
    
        delete p1;  // error: 不能 delete 由 malloc() 返回的指针
        free(p2);   // error: 不能 free() new 出来的对象
    }
    

    最后的 delete、free 在有的实现中可能正常工作,有的会导致运行时错误。

    例外

    有的应用中禁止异常,如 life-critical 和硬实时系统。但是很多针对异常的禁用只是迷信,或是担心导致旧代码资源管理上的混乱。如果是这种情况,可以考虑 nothrow 版本的 new

    代码检查建议

    标记显式的 malloc/free 调用

    R.11: 避免显式调用 new / delete

    new 返回的指针应该属于资源句柄(在资源句柄的析构中自动调用 delete)。如果 new 返回值赋给了裸指针,可能导致资源泄露。

    在大型项目中,如果在应用代码中(而不是在专门资源管理类中)出现 delete,那多半会有 bug:如果代码里有几处 delete 调用,你怎么保证没有多调用或者少调用?这类 bug 不一定能立即发现,可能在潜伏一段时间后,在某次代码维护/重构时暴露。

    代码检查建议

    针对显式的 new / delete 给出警告,建议使用 make_unique 替代

    R.12: 显式资源分配的结果应立即给到资源管理对象

    否则,一旦抛异常或返回将导致资源泄露

    反面例子

    void func(const string& name)
    {
        // 打开文件
        FILE* f = fopen(name, "r");
        vector<char> buf(1024);
        // 关闭文件
        auto _ = finally([f] { fclose(f); });
        // ...
    }
    

    buf 分配空间可能失败抛异常,导致 f 文件句柄泄露

    正面例子

    void func(const string& name)
    {
        ifstream f{name}; 
        vector<char> buf(1024);
        // ...
    }
    

    文件句柄在 ifstream 内部,ifstream 销毁时自动 fclose 文件句柄,简单、安全、高效。

    代码检查建议

    标记那些用来初始化指针的显式资源分配

    R.13: 在一条语句中,最多只能有一个显式资源分配

    如果在一条语句中执行两个显式资源分配,可能导致资源泄露。因为很多子表达式的求值顺序(包括函数参数)是未定义的。

    例子

    void fun(shared_ptr sp1, shared_ptr sp2);
    

    如果像下面这样调用 fun()

    // BAD: 可能泄露
    fun(shared_ptr(new Widget(a, b)), shared_ptr(new Widget(c, d)));
    

    上述调用是“异常不安全”(exception-unsafe)的,因为编译器可能会对创建两个参数的表达式重新排序。特别是编译器可能交叉执行两个子表达式:先给 sp1、sp2 分配内存空间、然后调用 Widget 的构造。如果此时在构造某一个参数的时候抛出异常,则另一个对象的内存不会被释放!

    解决这个问题也很简答,不在一条语句里出现多个显式资源分配即可。例如;

    // 稍好,但有点乱
    shared_ptr sp1(new Widget(a, b));
    fun(sp1, new Widget(c, d));
    

    最好的办法是完全避免显式资源分配,而是通过工厂函数返回拥有的对象:

    // 最佳实践
    fun(make_shared(a, b), make_shared(c, d));
    

    如果没有像 make_shared、make_unique 这样的工厂函数,自己封装一个。

    代码检查建议

    如果一条语句内有多个显式资源分配,标记该语句

    R.14: 避免使用 [] 参数,用 span 替代

    数组形参退化为指针,丢失数组大小信息,容易导致边界错误。用 span 可以保留数组大小信息。

    例子

    // 不推荐
    void f(int[]);
    
    // 不推荐指针指向多个对象
    // 指针应该指向单个对象(见 R.2)
    void f(int*);
    
    // 推荐
    void f(gsl::span<int>);
    

    R.15: 分配/释放操作要成对重载

    否则将导致混乱

    例子

    class X {
        void* operator new(size_t s);
        void operator delete(void*);
    };
    

    如果希望内存不被释放,用 =delete 明确禁止释放操作。

    代码检查建议

    标记不成对的分配/释放操作

  • 相关阅读:
    物联网浏览器(IoTBrowser)-使用深度学习开发防浸水远程报警
    c#中的析构函数
    springMvc的简介
    大数据技术训练舱:Redis的分布式实践(上)从零开始编译、安装、配置Redis6,规范化搭建Java工程测试
    C#:实现平方数序列算法(附完整源码)
    zemax---单透镜设计实例
    2022年10月21日数据库实验内容
    IDEA设置Maven 镜像
    DSP篇--C6678功能调试系列之Nor_FLASH调试
    物联网技术融合:ZETA联盟会员推出支持ZETA通信协议的BLE蓝牙网关
  • 原文地址:https://www.cnblogs.com/tengzijian/p/17503953.html