如何为c++智能指针提供自定义删除器？ (Deleter应用场景)

#include 
#include 
struct LogDeleter {
void operator()(int* p) const {
std::cout << "Deleting int at " << p << "\n";
delete p;
}
};
auto sp1 = std::shared_ptr(new int(42), LogDeleter{}); // OK：类型自动推导
auto sp2 = std::shared_ptr(new int(42), 
[](int* p) { std::cout << "lambda delete\n"; delete p; }); // OK：无捕获 lambda 可隐式转换
auto sp3 = std::shared_ptr(new int(42),
std::function)>([](int p) { delete p; })); // OK，但有额外开销

• 不需要模板参数声明删除器类型，这是和 unique_ptr 最关键的区别
• 捕获变量的 lambda 可直接传入（因为构造函数接受通用可调用对象），但注意闭包生命周期不能短于 shared_ptr
• 避免把大对象（如含缓冲区的 functor）反复拷贝进控制块，影响性能

常见 Deleter 错误与资源泄漏风险

自定义删除器出错往往不报编译错误，而是导致未定义行为或资源泄漏。典型问题包括：

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

• unique_ptr 忘记指定数组特化，仍用默认 delete（应为 delete[]）

• 删除器中抛异常：C++11 起，unique_ptr 析构时若删除器抛异常会调用 std::terminate

• 把非空终止字符串传给 std::string 构造函数后，用 c_str() 得到的指针被 unique_ptr 管理并误删

  

  甲骨文AI协同平台

  专门用于甲骨文研究的革命性平台

  下载

• C API 返回的“借用指针”被误用为独占所有权（如 SDL_GetKeyboardState 返回栈/全局内存，不该 delete）

• 删除器必须是 noexcept（尤其对 unique_ptr）；若逻辑可能失败，应在删除器内吞掉异常并记录错误

• 对 C 数组，优先用 std::unique_ptr + 默认删除器，而非手动写 delete[] 删除器

• 涉及 C 库资源时，务必查清所有权语义：是 caller owns 还是 library owns

Deleter 的实际应用场景

真正需要自定义删除器，不是为了“炫技”，而是对接外部系统所有权契约：

• 封装 C API：如 sqlite3_stmt 用 sqlite3_finalize，pthread_mutex_t 用 pthread_mutex_destroy
• 内存池/arena 分配：用池的 deallocate 替代 delete
• 文件描述符/句柄：Linux int fd 用 close，Windows HANDLE 用 CloseHandle
• 异步 I/O 中的 completion token 或 buffer：需调用特定回收接口，而非简单释放内存

这些场景的共同点是：资源生命周期不由 new/delete 控制，标准删除器完全失效。此时删除器不是“附加功能”，而是正确性的必要条件。

别把删除器当成通用回调——它只该做一件事：释放底层资源。复杂清理逻辑（如先 flush 再 close）应封装进 RAII 类型本身，而不是塞进删除器里。