如何用智能指针管理第三方库资源自定义删除器实践案例-C++-PHP中文网

标准智能指针无法直接管理所有第三方库资源的原因是它们默认使用delete操作符释放资源，而第三方库通常需要特定的销毁函数。1. 第三方库资源如c库内存（malloc/free）、文件句柄（fopen/fclose）或图形库api（create_texture/destroy_texture）需用对应函数释放；2. 若用默认delete释放这些资源，会导致未定义行为，例如内存泄漏或程序崩溃；3. 自定义删除器通过提供匹配的释放逻辑，使智能指针能正确管理这类资源。实现方式包括：1. lambda表达式适合简单、无状态的清理逻辑；2. 函数指针适用于复用已有c风格api；3. functor支持复杂逻辑和状态维护。实际项目中选择策略为：1. 独占所有权用std::unique_ptr，共享所有权用std::shared_ptr；2. 删除逻辑简单时选lambda或函数指针，复杂或需状态时选functor；3. 性能敏感场景优先考虑unique_ptr与lambda组合。

如何用智能指针管理第三方库资源自定义删除器实践案例

在C++开发中，尤其当我们需要与C语言风格的库或不提供C++RAII（资源获取即初始化）机制的第三方库交互时，智能指针配合自定义删除器是管理资源的关键。它能确保资源在不再需要时被正确释放，避免内存泄漏和其他资源管理问题，让代码更健壮、更安全。

解决方案

管理第三方库资源的核心在于理解其资源的生命周期管理方式，并将其“嫁接”到C++的智能指针机制上。通常，第三方库会提供一对函数：一个用于创建/获取资源（例如

create_handle()

登录后复制

或

open_file()

登录后复制

），另一个用于销毁/释放资源（例如

destroy_handle()

登录后复制

或

close_file()

登录后复制

）。标准库的

std::unique_ptr

登录后复制

和

std::shared_ptr

登录后复制

默认使用

delete

登录后复制

操作符来释放内存，但这显然不适用于那些需要特定函数来释放的资源。

这时候，自定义删除器就派上用场了。我们可以为智能指针提供一个自定义的函数对象（可以是lambda表达式、函数指针或一个带有

operator()

登录后复制

的结构体），告诉它在资源不再被引用时，应该调用哪个函数来释放资源。

以一个假设的第三方库为例：

// 假设的第三方库API
namespace ThirdPartyLib {
    struct ResourceHandle {
        int id;
        // 更多资源相关数据
    };

    ResourceHandle* create_resource() {
        // 模拟资源创建，可能涉及内存分配、文件打开等
        static int counter = 0;
        ResourceHandle* handle = new ResourceHandle{++counter};
        std::cout << "Resource " << handle->id << " created." << std::endl;
        return handle;
    }

    void destroy_resource(ResourceHandle* handle) {
        // 模拟资源销毁
        if (handle) {
            std::cout << "Resource " << handle->id << " destroyed." << std::endl;
            delete handle; // 假设内部是new分配的
        }
    }

    // 另一个例子：文件句柄
    FILE* open_my_file(const char* filename, const char* mode) {
        FILE* f = fopen(filename, mode);
        if (f) {
            std::cout << "File '" << filename << "' opened." << std::endl;
        }
        return f;
    }

    void close_my_file(FILE* f) {
        if (f) {
            std::cout << "File closed." << std::endl;
            fclose(f);
        }
    }
}

// 使用unique_ptr管理ThirdPartyLib::ResourceHandle
{
    // 定义一个lambda作为删除器
    auto resource_deleter = [](ThirdPartyLib::ResourceHandle* p) {
        ThirdPartyLib::destroy_resource(p);
    };
    std::unique_ptr<ThirdPartyLib::ResourceHandle, decltype(resource_deleter)>
        resource_ptr(ThirdPartyLib::create_resource(), resource_deleter);

    // 资源在resource_ptr超出作用域时自动销毁
} // resource_ptr在这里超出作用域，resource_deleter被调用

std::cout << "---" << std::endl;

// 使用unique_ptr管理FILE*
{
    // 对于C标准库的fclose，可以直接用函数指针
    std::unique_ptr<FILE, decltype(&ThirdPartyLib::close_my_file)>
        file_ptr(ThirdPartyLib::open_my_file("temp.txt", "w"), &ThirdPartyLib::close_my_file);

    if (file_ptr) {
        fprintf(file_ptr.get(), "Hello, custom deleter!\n");
    }
} // file_ptr在这里超出作用域，close_my_file被调用

登录后复制

通过这种方式，无论资源是如何获取的，只要我们知道对应的释放函数，就能将其无缝集成到C++的RAII范式中，大大提升代码的健壮性和可维护性。

为什么标准智能指针无法直接管理所有第三方库资源？

这其实是个很基础但又常被忽略的问题。标准库提供的

std::unique_ptr

登录后复制

和

std::shared_ptr

登录后复制

，它们默认的资源释放行为是调用

delete

登录后复制

操作符（或

delete[]

登录后复制

对于数组类型）。这与C++中

new

登录后复制

关键字分配的内存是完美匹配的。然而，现实世界中的资源管理远不止

new/delete

登录后复制

这么简单。

想象一下，你可能在用一个老旧的C库，它用

malloc

登录后复制

分配内存，你需要用

free

登录后复制

来释放；或者一个图形库，它提供

create_texture()

登录后复制

和

destroy_texture()

登录后复制

这样的API；又或者文件操作，

fopen

登录后复制

之后得用

fclose

登录后复制

。这些资源的管理方式都与C++的

new/delete

登录后复制

机制不同。如果你尝试用默认的

std::unique_ptr

登录后复制

去管理一个

malloc

登录后复制

出来的指针，当智能指针析构时，它会错误地调用

delete

登录后复制

，这会导致未定义行为，轻则内存泄漏，重则程序崩溃。

所以，关键点在于“资源获取”和“资源释放”必须是匹配的。智能指针的默认行为只匹配

new

登录后复制

出来的资源。对于那些非

new

登录后复制

获取的资源，我们必须明确告诉智能指针，在资源生命周期结束时，应该调用哪个特定的函数来完成清理工作，这就是自定义删除器的根本原因。它提供了一个钩子，让我们能够插入任何符合资源清理逻辑的代码。

ImgCleaner

一键去除图片内的任意文字，人物和对象

220

查看详情

自定义删除器有哪些常见的实现方式？

自定义删除器提供了极大的灵活性，主要有以下几种实现方式，每种都有其适用场景和优缺点：

Lambda 表达式：这是现代C++中最常用、最简洁的方式，特别适合于简单的、不带状态的删除逻辑。
```
std::unique_ptr<SomeType, decltype([](SomeType* p){ /* cleanup logic */ })>
    ptr(raw_ptr, [](SomeType* p){ /* cleanup logic */ });
```
登录后复制
- 优点：代码内联，通常能获得更好的性能；语法简洁，直接在创建智能指针的地方定义删除逻辑，可读性高；可以捕获外部变量（如果删除逻辑需要一些上下文信息）。
- 缺点：如果删除逻辑复杂或需要在多个地方复用，可能会导致代码冗余。
函数指针：适用于那些已经存在、且签名与删除器要求匹配的全局函数或静态成员函数。
```
void my_cleanup_func(SomeType* p) { /* cleanup logic */ }
std::unique_ptr<SomeType, decltype(&my_cleanup_func)>
    ptr(raw_ptr, &my_cleanup_func);
```
登录后复制
- 优点：可以复用已有的C风格API函数（如
```
free
```
  登录后复制
  ,
```
fclose
```
  登录后复制
  ）；类型明确，易于理解。
- 缺点：不能捕获状态；如果需要自定义逻辑，需要单独定义一个函数。
Functor (函数对象)：这是一个带有
```
operator()
```
登录后复制
的类或结构体。它最适合需要维护状态，或者删除逻辑比较复杂、需要封装的情况。
```
struct MyDeleter {
    void operator()(SomeType* p) const {
        // cleanup logic, potentially using member variables
    }
};
std::unique_ptr<SomeType, MyDeleter> ptr(raw_ptr); // MyDeleter是默认构造的
```
登录后复制
- 优点：可以拥有成员变量，从而存储删除时所需的额外信息（例如日志句柄、配置参数等）；可以实现更复杂的删除逻辑；可复用性强，可以作为独立的类型在多个地方使用。
- 缺点：相比lambda或函数指针，代码量稍多，需要额外定义一个类。

选择哪种方式，通常取决于删除逻辑的复杂度和是否需要状态。对于简单的、一次性的清理，lambda是首选。对于已有的C风格API，函数指针很方便。而对于需要状态管理或复杂逻辑的场景，functor则提供了最佳的封装性。

在实际项目中如何选择合适的智能指针和删除器策略？

在实际项目中，选择合适的智能指针和删除器策略，是一个需要综合考虑资源所有权、生命周期、性能以及代码可读性的决策。这并非一刀切的问题，而是基于具体场景的权衡。

首先，明确资源所有权语义是第一步。

独占所有权：如果一个资源在任何给定时间只能由一个对象或模块管理，并且当这个对象或模块不再需要它时，资源就应该被释放，那么
```
std::unique_ptr
```
登录后复制
是不二之选。它能清晰地表达资源所有权的转移，避免了悬空指针和二次释放的问题。绝大多数第三方库资源管理都倾向于独占所有权。
共享所有权：如果资源需要被多个不相关的对象或模块共同使用，并且只有当所有使用者都放弃了对它的引用时，资源才应该被释放，那么
```
std::shared_ptr
```
登录后复制
是合适的。例如，一个大型的纹理对象可能被多个渲染组件共享，或者一个数据库连接池中的连接被多个请求线程共享。需要注意的是，
```
std::shared_ptr
```
登录后复制
会引入引用计数开销，且可能导致循环引用问题，需要谨慎使用
```
std::weak_ptr
```
登录后复制
来打破循环。

其次，根据删除逻辑的复杂度和可复用性选择删除器实现。

简单、无状态的清理：如果删除操作仅仅是调用一个不带额外参数的函数（例如
```
fclose(FILE*)
```
登录后复制
或
```
curl_easy_cleanup(CURL*)
```
登录后复制
），那么lambda表达式或函数指针是最佳选择。它们简洁、高效，并且能很好地与
```
unique_ptr
```
登录后复制
配合。对于
```
std::unique_ptr
```
登录后复制
，lambda表达式的类型通常会被编译器优化掉，不会增加额外的存储开销。
复杂、有状态的清理：如果删除操作需要访问额外的上下文信息（例如，关闭一个日志句柄时需要记录一条日志到特定的日志文件），或者删除逻辑本身比较复杂，需要在多个地方复用，那么自定义的 Functor 类（带有
```
operator()
```
登录后复制
的结构体）是更好的选择。它可以封装状态和复杂的清理逻辑，使得代码更模块化、更易于维护。

举个例子，假设你正在集成一个图形库：

纹理管理：
```
Texture* create_texture(...)
```
登录后复制
和
```
void destroy_texture(Texture*)
```
登录后复制
。如果一个纹理在游戏中可能被多个精灵或UI元素引用，那么
```
std::shared_ptr<Texture, decltype(&destroy_texture)>
```
登录后复制
配合函数指针可能是合适的。这样，只要有一个对象还在使用纹理，它就不会被释放。
渲染上下文：
```
GraphicsContext* init_context(...)
```
登录后复制
和
```
void shutdown_context(GraphicsContext*)
```
登录后复制
。通常一个应用程序只有一个主渲染上下文，或者每个窗口一个，这种情况下，
```
std::unique_ptr<GraphicsContext, decltype(&shutdown_context)>
```
登录后复制
配合函数指针就足够了。