shared_ptr的自定义删除器使其能灵活管理非内存资源，通过lambda、函数对象或普通函数指定释放逻辑，确保文件句柄、数组等资源安全释放，实现RAII。
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 #include #include // For FILE* operations#include // 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( 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( 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( 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 #include #include // 假设有一个自定义的日志系统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( 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 #include #include // 普通函数作为删除器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( 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++中成为了首选。
使用自定义删除器时需要注意哪些潜在问题和最佳实践？
虽然自定义删除器功能强大，但使用时也有些地方需要留心，否则可能会引入新的问题。这就像你拿到一把瑞士军刀，功能多是多，但用不好也可能伤到自己。
1.
shared_ptr
的类型与删除器
这是一个比较隐晦但非常重要的问题。
std::shared_ptr
的类型实际上是包含其删除器类型的。如果你使用Lambda表达式作为删除器，那么这个Lambda的类型是编译器生成的唯一类型。这意味着：
auto lambda_deleter = [](FILE* f) { /* ... */ };std::shared_ptr ptr1(fopen("a.txt", "w"), lambda_deleter);// ptr1 的实际类型是 std::shared_ptr
如果你想把这个
ptr1
赋值给另一个
std::shared_ptr
（没有指定删除器类型），或者传递给一个期望
std::shared_ptr
作为参数的函数，可能会遇到编译错误。因为
std::shared_ptr
和
std::shared_ptr
是两种不同的类型。
最佳实践：
使用
auto
：如果你不打算将
shared_ptr
存储在容器中，或者不需要在接口中暴露其具体删除器类型，直接用
auto
声明变量是最方便的，编译器会帮你推断出完整的类型。类型擦除（Type Erasure）：如果确实需要统一
shared_ptr
的类型，可以考虑将它存储为
std::shared_ptr
或者
std::shared_ptr
。例如，
std::shared_ptr
可以管理任何类型的指针，但你需要确保删除器知道如何正确处理它。不过，这会让你在访问实际对象时需要进行
static_cast
或
dynamic_cast
，增加了复杂性。包装器或工厂函数：为特定资源创建返回
std::shared_ptr
的工厂函数，内部处理删除器细节。
2.
make_shared
与自定义删除器
std::make_shared
无法直接与自定义删除器一起使用。
make_shared
的优势在于它能够一次性分配对象内存和控制块内存，从而提高效率。但它假设你希望通过
new T
来构造对象。如果你有自定义的资源获取方式（如
fopen
）或自定义的删除逻辑，你就必须使用
new
来获取原始指针，然后将其传递给
shared_ptr
的构造函数。
// 错误示范：不能这样用// auto ptr = std::make_shared(fopen("test.txt", "w"), [](FILE* f){ fclose(f); });// 正确示范：FILE* f_raw = fopen("test.txt", "w");auto ptr = std::shared_ptr(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
的拷贝，否则会导致重复释放。
5. 性能考量（通常不显著）
自定义删除器，特别是复杂的函数对象或Lambda，可能会比默认的
delete
操作带来轻微的性能开销，主要是因为：
删除器对象本身可能需要被复制到
shared_ptr
的控制块中。调用删除器可能涉及间接函数调用。
在绝大多数应用中，这种开销可以忽略不计。只有在极端性能敏感的场景下，才需要考虑这方面的影响。我的经验是，为了代码的清晰、安全和健壮性，这种微小的开销是完全值得的。
总的来说，
shared_ptr
的自定义删除器是一个非常强大的工具，它扩展了智能指针的适用范围，让我们可以以统一且安全的方式管理各种类型的资源。理解其工作原理和潜在的陷阱，能够帮助我们写出更可靠、更易维护的C++代码。
以上就是C++shared_ptr自定义删除器使用方法的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1474147.html
微信扫一扫 
支付宝扫一扫 
