C++shared_ptr自定义删除器使用方法-C++-PHP中文网

shared_ptr的自定义删除器使其能灵活管理非内存资源，通过lambda、函数对象或普通函数指定释放逻辑，确保文件句柄、数组等资源安全释放，实现RAII。

c++shared_ptr自定义删除器使用方法

shared_ptr

登录后复制

的自定义删除器，本质上是赋予了智能指针超越简单

delete

登录后复制

操作的能力，让我们能以更灵活、更安全的方式管理那些非内存堆资源，比如文件句柄、网络套接字，甚至是C风格的数组，确保它们在不再需要时，能以正确的方式被释放。这就像给一个通用工具加上了针对特定任务的专属插件，让它变得更加强大和精准。

解决方案

std::shared_ptr

登录后复制

默认情况下会使用

delete

登录后复制

操作符来释放它所管理的内存。然而，在很多场景下，我们管理的并非简单的

new

登录后复制

出来的对象，而是通过C风格API获取的资源（如

fopen

登录后复制

返回的

FILE*

登录后复制

，或者某些库返回的句柄），这些资源需要特定的函数（如

fclose

登录后复制

，

CloseHandle

登录后复制

）来释放。这时，我们就需要为

shared_ptr

登录后复制

提供一个“自定义删除器”（Custom Deleter），告诉它在引用计数归零时，应该调用哪个函数或哪个可调用对象来释放资源。

自定义删除器可以是：

Lambda表达式：最常见也最简洁的方式，尤其适合就地定义简单的删除逻辑。
函数对象（Functor）：当删除逻辑比较复杂，或者需要携带状态时，函数对象是一个好选择。
普通函数：如果删除逻辑是一个独立的、不依赖状态的全局函数，也可以直接传递函数指针。

使用时，自定义删除器作为

shared_ptr

登录后复制

构造函数的第二个参数传入，它会接收一个指向被管理资源的原始指针作为参数。

立即学习“C++免费学习笔记（深入）”；

为什么我们需要为shared_ptr定制删除器？

我时常会遇到这样的场景：从某个C库获取了一个资源句柄，比如打开了一个文件得到

FILE*

登录后复制

，或者创建了一个线程句柄。这些东西如果直接用

std::unique_ptr

登录后复制

或

std::shared_ptr

登录后复制

默认的

delete

登录后复制

去管理，那肯定是灾难性的。

delete

登录后复制

只会尝试释放通过

new

登录后复制

分配的内存，而

FILE*

登录后复制

之类的通常是通过

malloc

登录后复制

或库内部机制分配的，需要

fclose()

登录后复制

这样的特定函数来关闭。这就是自定义删除器大放异彩的地方。

它不仅仅是避免内存泄漏，更是为了实现“资源获取即初始化”（RAII）原则，将资源的生命周期管理与对象生命周期绑定。想象一下，你打开了一个文件，然后代码在某个地方抛了异常，或者提前返回了。如果没有RAII，你很可能忘记调用

fclose

登录后复制

，导致文件句柄泄漏。但如果用

shared_ptr

登录后复制

带着自定义删除器，无论代码如何跳转，只要

shared_ptr

登录后复制

的引用计数归零，文件就一定会被安全关闭。这大大简化了错误处理和资源管理，让代码更健壮。对我来说，这是一种解放，让我可以更专注于业务逻辑本身，而不是纠结于各种资源释放的细节。

shared_ptr自定义删除器有哪些实现方式？代码示例？

自定义删除器的实现方式其实挺灵活的，选择哪种主要看你的具体需求和个人偏好。我个人最常用的是Lambda表达式，因为它简洁，而且可以捕获上下文变量，非常方便。

这里我们看几个具体的例子：

1. 使用Lambda表达式作为删除器 (最常用)

这种方式非常适合那些一次性的、不复杂的删除逻辑。

#include <iostream>
#include <memory>
#include <cstdio> // For FILE* operations
#include <vector> // For new int[] example

// 模拟一个C风格的资源获取和释放函数
FILE* open_my_file(const char* filename, const char* mode) {
    std::cout << "Opening file: " << filename << std::endl;
    return fopen(filename, mode);
}

int main() {
    // 示例1: 管理文件句柄 (FILE*)
    // 默认的shared_ptr会尝试delete FILE*，这显然是错的
    // 我们需要用fclose来关闭文件
    auto file_ptr = std::shared_ptr<FILE>(
        open_my_file("example.txt", "w"),
        [](FILE* f) { // 这是一个Lambda删除器
            if (f) {
                std::cout << "Lambda Deleter: Closing file." << std::fclose(f) << std::endl;
            }
        }
    );

    if (file_ptr) {
        fprintf(file_ptr.get(), "Hello from shared_ptr with custom deleter!\n");
        std::cout << "File content written." << std::endl;
    } else {
        std::cerr << "Failed to open file." << std::endl;
    }

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

    // 示例2: 管理通过 new[] 分配的数组
    // 默认的shared_ptr会调用 delete p; 而不是 delete[] p;
    // 这会导致未定义行为，我们需要 delete[]
    auto array_ptr = std::shared_ptr<int>(
        new int[5]{1, 2, 3, 4, 5},
        [](int* p) { // 另一个Lambda删除器
            std::cout << "Lambda Deleter: Deleting int array." << std::endl;
            delete[] p;
        }
    );

    for (int i = 0; i < 5; ++i) {
        std::cout << "Array element " << i << ": " << array_ptr.get()[i] << std::endl;
    }

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

    // 示例3: Lambda捕获变量 (比如一个日志器)
    std::string log_prefix = "[MyResource]";
    auto resource_ptr = std::shared_ptr<void>(
        nullptr, // 只是一个示例，实际中会是某个资源指针
        [log_prefix](void* p) { // Lambda捕获log_prefix
            std::cout << log_prefix << " Resource (void*) is being released." << std::endl;
            // 实际中这里会有资源释放逻辑
        }
    );
    // 这里的resource_ptr虽然是nullptr，但其deleter依然有效
    // 当resource_ptr离开作用域时，deleter会被调用。

    return 0; // file_ptr 和 array_ptr 在这里离开作用域，删除器会被调用
}

登录后复制

2. 使用函数对象（Functor）作为删除器

当删除逻辑比较复杂，或者需要封装状态，或者希望删除器可以复用时，函数对象是一个很好的选择。

#include <iostream>
#include <memory>
#include <cstdio>

// 假设有一个自定义的日志系统
class Logger {
public:
    void log(const std::string& msg) const {
        std::cout << "[Logger] " << msg << std::endl;
    }
};

// 函数对象删除器，用于关闭文件并记录日志
struct FileCloser {
    Logger logger; // 可以包含状态

    FileCloser(const Logger& l) : logger(l) {}

    void operator()(FILE* f) const {
        if (f) {
            logger.log("Functor Deleter: Closing file.");
            std::fclose(f);
        }
    }
};

int main() {
    Logger my_logger;
    auto file_ptr_functor = std::shared_ptr<FILE>(
        fopen("functor_example.txt", "w"),
        FileCloser(my_logger) // 传入函数对象实例
    );

    if (file_ptr_functor) {
        fprintf(file_ptr_functor.get(), "Content from functor deleter.\n");
    }

    return 0;
}

登录后复制

3. 使用普通函数作为删除器

如果删除逻辑是一个不依赖任何状态的独立函数，可以直接传递函数指针。

#include <iostream>
#include <memory>
#include <cstdio>

// 普通函数作为删除器
void close_file_global(FILE* f) {
    if (f) {
        std::cout << "Global Function Deleter: Closing file." << std::endl;
        std::fclose(f);
    }
}

int main() {
    auto file_ptr_global_func = std::shared_ptr<FILE>(
        fopen("global_func_example.txt", "w"),
        close_file_global // 直接传递函数名，它会隐式转换为函数指针
    );

    if (file_ptr_global_func) {
        fprintf(file_ptr_global_func.get(), "Content from global function deleter.\n");
    }

    return 0;
}

登录后复制

可以看到，无论是哪种方式，核心思想都是一样的：提供一个可调用对象，它接收一个原始指针，并在

shared_ptr

登录后复制

的引用计数归零时被调用。Lambda表达式因其简洁性和捕获能力，在现代C++中成为了首选。

使用自定义删除器时需要注意哪些潜在问题和最佳实践？

虽然自定义删除器功能强大，但使用时也有些地方需要留心，否则可能会引入新的问题。这就像你拿到一把瑞士军刀，功能多是多，但用不好也可能伤到自己。

稿定抠图

AI自动消除图片背景

查看详情

shared_ptr

登录后复制

的类型与删除器

这是一个比较隐晦但非常重要的问题。

std::shared_ptr<T>

登录后复制

的类型实际上是包含其删除器类型的。如果你使用Lambda表达式作为删除器，那么这个Lambda的类型是编译器生成的唯一类型。这意味着：

auto lambda_deleter = [](FILE* f) { /* ... */ };
std::shared_ptr<FILE> ptr1(fopen("a.txt", "w"), lambda_deleter);
// ptr1 的实际类型是 std::shared_ptr<FILE, decltype(lambda_deleter)>

登录后复制

如果你想把这个

ptr1

登录后复制

赋值给另一个

std::shared_ptr<FILE>

登录后复制

（没有指定删除器类型），或者传递给一个期望

std::shared_ptr<FILE>

登录后复制

作为参数的函数，可能会遇到编译错误。因为

std::shared_ptr<FILE, decltype(lambda_deleter)>

登录后复制

和

std::shared_ptr<FILE>

登录后复制

是两种不同的类型。

最佳实践：

使用
auto
登录后复制
：如果你不打算将
```
shared_ptr
```
登录后复制
存储在容器中，或者不需要在接口中暴露其具体删除器类型，直接用
```
auto
```
登录后复制
声明变量是最方便的，编译器会帮你推断出完整的类型。
类型擦除（Type Erasure）：如果确实需要统一
```
shared_ptr
```
登录后复制
的类型，可以考虑将它存储为
```
std::shared_ptr<BaseType>
```
登录后复制
或者
```
std::shared_ptr<void>
```
登录后复制
。例如，
```
std::shared_ptr<void>
```
登录后复制
可以管理任何类型的指针，但你需要确保删除器知道如何正确处理它。不过，这会让你在访问实际对象时需要进行
```
static_cast
```
登录后复制
或
```
dynamic_cast
```
登录后复制
，增加了复杂性。
包装器或工厂函数：为特定资源创建返回
```
std::shared_ptr<T>
```
登录后复制
的工厂函数，内部处理删除器细节。

make_shared

登录后复制

与自定义删除器

std::make_shared

登录后复制

无法直接与自定义删除器一起使用。

make_shared

登录后复制

的优势在于它能够一次性分配对象内存和控制块内存，从而提高效率。但它假设你希望通过

new T

登录后复制

来构造对象。如果你有自定义的资源获取方式（如

fopen

登录后复制

）或自定义的删除逻辑，你就必须使用

new

登录后复制

来获取原始指针，然后将其传递给

shared_ptr

登录后复制

的构造函数。

// 错误示范：不能这样用
// auto ptr = std::make_shared<FILE>(fopen("test.txt", "w"), [](FILE* f){ fclose(f); });

// 正确示范：
FILE* f_raw = fopen("test.txt", "w");
auto ptr = std::shared_ptr<FILE>(f_raw, [](FILE* f){ if(f) fclose(f); });

登录后复制

3. 删除器的异常安全性

自定义删除器在执行资源释放时，不应该抛出异常。如果删除器抛出异常，

std::terminate

登录后复制

会被调用，程序会立即终止。这是因为

shared_ptr

登录后复制

在析构时调用删除器，而析构函数中抛出异常通常被认为是设计缺陷，会导致未定义行为或资源泄漏。

最佳实践：

确保你的删除器内部逻辑是异常安全的，例如，在关闭文件或释放资源时，检查返回值，但不要在失败时抛出异常。
如果资源释放函数本身可能失败，你可以选择记录错误，而不是抛出异常。

4. 资源所有权和原始指针的生命周期

当你将一个原始指针传递给

shared_ptr

登录后复制

并为其指定删除器时，

shared_ptr

登录后复制

就接管了该资源的完整所有权。这意味着：

不要再手动
```
delete
```
登录后复制
或释放这个原始指针。
确保原始指针在传递给
```
shared_ptr
```
登录后复制
之前是有效的，并且其生命周期不会在
```
shared_ptr
```
登录后复制
接管之前结束。
避免将同一个原始指针传递给多个独立的
```
shared_ptr
```
登录后复制
实例，除非它们是
```
shared_ptr
```
登录后复制
的拷贝，否则会导致重复释放。