std::out_ptr是为C API输出参数设计的RaiI封装器，不接管所有权也不做类型转换；误当智能指针转换器用会导致崩溃或泄漏，仅适用于T**形参且C函数malloc后写入新地址的场景。
std::out_ptr 不能直接配合 C 风格 API 使用——它本身不是“转换工具”，而是为“输出参数”场景设计的 RAII 封装器，用错就崩溃或内存泄漏。
std::out_ptr 是什么，为什么不能当“智能指针转换器”用
它不接管原始指针所有权，也不做类型转换；它只是在函数调用前后自动把 std::unique_ptr 或 std::shared_ptr 的裸指针地址传给 C 函数，并在调用后根据需要重置智能指针（比如 C 函数 malloc 了新内存并写入指针地址）。常见误解是把它当成 std::unique_ptr → T* 的安全转换接口，其实不是。
容易踩的坑：
- 对只读 C 函数（如
void inspect(const Foo*)）误用std::out_ptr：它会试图解引用并赋值，导致未定义行为 - 传给非
T**类型的参数（比如void**或int**），编译失败或静默错误 - C 函数没按约定写入新地址，但
std::out_ptr仍调用reset()，导致原资源被提前释放
正确配合 C API 的典型场景：输出参数 + malloc 分配
适用于 C 函数形如 int create_foo(Foo** out_foo)，且内部调用 malloc 或等效分配，并将结果写入 *out_foo。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 确保 C 函数签名明确接收
T**，且文档/头文件说明它会写入新分配对象 - 用
std::unique_ptr初始化为空，再传std::out_ptr(ptr) - 检查 C 函数返回值，失败时
ptr应保持为空，避免误reset
示例：
std::unique_ptr fp(NULLptr, fclose); if (fopen_s(&fp, "data.txt", "r") == 0) { /* OK */ } // ❌ 错误：fopen_s 是 microsoft 扩展，签名是 errno_t fopen_s(FILE**, ...), 不是标准 C // ✅ 正确（POSIX）： std::unique_ptr fp(nullptr, &fclose); auto out = std::out_ptr(fp); if (fopen_r("data.txt", out.get()) != 0) { /* error */ } // 假设 fopen_r(int*, FILE**) 是你封装的 C 接口，内部 malloc 并赋值 *out std::in_ptr 和 std:: inout_ptr 在哪用、有什么区别
std::in_ptr 用于只读输入（传 T* 给 C 函数），std::inout_ptr 用于“先读再写”的混合场景（如 C 函数读旧值、realloc 后写回新地址）。三者都不做类型转换，也不兼容不同智能指针之间的互转。
关键差异：
-
std::out_ptr：调用前取get()地址，调用后调用reset(new_ptr) -
std::in_ptr：只取get()，全程不修改智能指针状态 -
std::inout_ptr：调用前取get()，调用后若 C 函数修改了指针值，则用新值reset，否则不重置
注意：std::inout_ptr 要求 C 函数确实会写回地址（如 int resize_buffer(Buffer**, size_t)），否则行为等同于 std::in_ptr，但多一次空检查开销。
替代方案：什么时候该放弃 out_ptr，手写 RAII 封装
当 C API 行为不规范（比如不保证写入、写入后不负责释放、或需要自定义释放逻辑），std::out_ptr 的自动 reset 反而危险。
更稳妥的做法：
- 用
std::unique_ptr::release()+ 手动reset(new_ptr)，显式控制时机 - 为 C 类型写专属 RAII 类（如
Struct c_file { FILE* p; ~c_file() { if(p) fclose(p); } }） - 对复杂生命周期（如 C 函数返回需由用户 free 的指针，但又可能返回 NULL 或已存在对象），
std::out_ptr完全不适用
真正容易被忽略的一点：c++23 的这些 ptr 模板都要求智能指针的 deleter 是可复制/可移动的，且 operator* 和 get() 行为符合预期——自定义 deleter 若捕获了局部变量或含状态，std::out_ptr 构造时可能引发未定义行为。