<p>不能直接传 std::shared_ptr 给 C 函数，因其是含引用计数的对象，而 C 只接受裸指针；用 ptr.get() 仅在 C 函数不保存指针时安全，长期持有需移交所有权、封装 shared_ptr 到 void* 或用 weak_ptr 防悬空，且内存分配/释放须同模块。</p>
为什么不能直接把 std::shared_ptr 传给 C 函数
C 函数只认裸指针（void* 或具体类型指针），而 std::shared_ptr 是个对象，有引用计数、控制块等额外状态。直接传 ptr.get() 虽然能拿到原始指针，但风险极大：C 函数若保存该指针并在后续回调中使用，而此时 shared_ptr 已销毁，就会导致悬空指针。
用 get() 的前提：C 函数只读不存留
如果 C 接口明确是“只临时使用、不保存、不异步回调”，那 ptr.get() 是最轻量的解法。常见于图像处理库（如 OpenCV 的 cv::Mat 构造）、日志函数、同步计算回调等场景。
-
some_c_func(ptr.get(), size);—— 安全，只要ptr生命周期覆盖整个调用 - 别传
&*ptr，它和ptr.get()等价，但可读性差且易误用 - 若 C 函数声明为
const T*，确保shared_ptr<t></t>持有非 const 对象，否则需static_cast<const t>(ptr.get())</const>
需要 C 函数长期持有时：必须移交所有权或绑定生命周期
典型场景：注册回调、设置句柄、传入线程池任务。此时不能靠 get()，得让 C 侧知道何时释放内存，或让 C++ 侧感知 C 的使用状态。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 方案一：移交所有权 → 用
ptr.release()，但仅适用于std::unique_ptr；shared_ptr不支持 release，必须改用unique_ptr或裸指针 + 自定义 deleter - 方案二：C 侧不管理内存，只存
shared_ptr副本 → 把shared_ptr包进void*参数（如set_callback(c_func, new std::shared_ptr<t>(ptr))</t>），并在 C 回调里static_cast<:shared_ptr>*>(user_data)</:shared_ptr>取出并解引用。注意：C 侧必须保证不泄漏该void*，且最终要delete static_cast<:shared_ptr>*>(p)</:shared_ptr> - 方案三：用
std::weak_ptr防循环引用 → 若 C 函数可能被长期持有且需安全访问，C++ 侧保存weak_ptr，回调时lock()获取临时shared_ptr，失败则跳过操作
跨语言边界时的常见坑
最容易被忽略的是 ABI 和析构时机错位。比如 C 函数在 DLL 卸载后调用回调，而 shared_ptr 的控制块分配在主程序堆上，DLL 里的 delete 可能崩溃。
立即学习“C++免费学习笔记（深入）”；
- 所有动态分配/释放必须发生在同一模块（同 DLL / 同 CRT 实例）；避免在 DLL 中 new，在 EXE 中 delete
- 若 C 接口要求提供
free_fn（如void (*free_fn)(void*)），务必传一个与分配器匹配的释放函数，而不是默认delete -
std::shared_ptr的自定义 deleter 必须是可复制的函数对象，不能捕获局部变量（lambda 捕获会失效）；推荐用普通函数或std::function+std::shared_ptr组合封装
真正麻烦的从来不是怎么传，而是谁负责释放、在哪释放、释放时对象是否还活着——这些得在接口契约里写清楚，光靠代码没法自动兜底。
