C++ 与 C 库互操作：ABI 与句柄所有权

链接、不透明句柄与错误值

先会读 C 函数声明、指针和 C++ 异常。本节对照scan.h 与 main.cpp解释链接及错误协议，示例未执行。

专题入口：C++ C ABI 边界：链接、不透明句柄与错误值 · C++ 原生资源所有权：接管、析构与借用 · C++ 完整实践：RAII 宿主连接 POSIX C 库 · C++ 原生边界排错：符号、释放器与异常政策

C++调用C库为什么需要extern C

C++调用C库为什么需要extern C：extern "C" 是语言链接声明，使 C++ 调用侧按相应链接约定引用 C 定义，避免默认 C++ 名称修饰造成符号不匹配。头文件用 __cplusplus 守卫，C 编译器不解析 C++ 语法；实现 scan.c 仍由 C 编译器处理。

不能把整个包含模板的 C++ 头文件塞进 C 链接块，也不能给同一个函数先声明 C++ 链接再换成 C 链接。语言链接本身不把类、std::string、异常或虚函数布局变成稳定公共协议。

C++消费的不透明句柄隐藏了什么

C++消费的不透明句柄隐藏了什么：公开 typedef struct scan scan 只让调用者持有指针，不让它依赖内部 mutex、路径数组或状态字段的布局。库可以修改实现结构而保持函数签名，但调用者不能 sizeof(scan)、栈上创建 scan 或自行访问字段。

不透明不等于任意二进制兼容。本项目静态库与宿主在同一工具链、架构和运行库约定下构建；跨版本发布还需要明确符号、调用约定、整数宽度、运行库及版本策略。这里只提供稳定边界的设计方法，不承诺跨编译器万能 ABI。

C++如何把C错误码转换成异常

C++如何把C错误码转换成异常：check 接收0或正的 POSIX 错误编号，非零则抛 std::system_error，配 std::generic_category。它接收函数返回的 code，不去读 errno；否则 pthread 错误和清理之后的错误来源会被混淆。

异常只存在于 C++ 宿主侧，C 实现返回整数错误码。若未来库实现改成 C++，C 入口必须捕获全部异常并转成协议错误，不能允许异常穿过普通 C 调用栈。当前没有回调，不需要为不存在的回调建立额外框架。

C++原生接口示例采用什么标准

C++原生接口示例采用什么标准：宿主采用 C++20、库采用 C11，依赖 POSIX pthread 与文件 API。CMake >=3.20 是工程最低声明，不代表本次验证过某个发行版上的组合；示例未执行，没有运行 configure 或编译。Linux/macOS 是理论适用平台，Windows 只说明 WSL Linux 路径。

选择标准的目的是延续已有 C++20 课程并明确分离编译边界，不需要第三方 FFI 生成器。先掌握值语义与 RAII，再阅读这一条 ABI 路线；C++ 入门不要求先完整学过 C，但阅读头文件需要认识指针、const 和错误返回协议。

独立练习

能否把std::string放进extern C接口就宣布ABI稳定？为什么不能在宿主sizeof(scan)？

先写出状态和资源归属，再对照答案；这些是推演练习，没有执行示例。

参考解答与检查条件

不能；语言链接没有规定C++类布局与运行库兼容。scan是不完整类型，宿主不了解其布局，应由库创建销毁并通过函数访问。

资料与适用边界

2026-10-17 核对 Linux read 手册、write 手册、close 的平台差异、pthread_create、pthread_join 与 POSIX mutex 规范镜像。Linux 手册中的实现差异不直接推广为 macOS 实测结果。The Open Group 的 POSIX 页面本次抓取被拒绝，不记为已成功核读。线程依赖的目标表达参考 CMake 3.20 FindThreads，没有执行它来探测本机。

C++ 链接与拥有关系参照 cppreference language linkage、unique_ptr；中文核对 Microsoft extern 说明，仅引用语言链接概念，不套用其 Windows 编译开关。文章采用独立组织的边界与失败推演，外链用于溯源，必要答案已在正文。

接管、析构与借用

先读前节句柄创建与错误返回协议，再沿main.cpp 的 unique_ptr 接管路径检查析构、借用和线程责任，示例未执行。

专题入口：C++ C ABI 边界：链接、不透明句柄与错误值 · C++ 原生资源所有权：接管、析构与借用 · C++ 完整实践：RAII 宿主连接 POSIX C 库 · C++ 原生边界排错：符号、释放器与异常政策

C++什么时候应该接管C句柄

C++什么时候应该接管C句柄：scan_create 成功后立即把 raw 交给带自定义删除器的 unique_ptr，删除器调用 scan_destroy，不能调用 delete 或 free。库拥有分配方式与内部资源清理顺序，宿主只拥有句柄的唯一销毁责任。

失败时 C 接口保证 out 为空，check 抛出不会遗失已交给调用方的资源；成功后接管使用无状态删除器，不包含额外可能失败的业务动作。若在接管前加入字符串分配或日志格式化，该步骤可能抛出并泄漏 raw，必须重新审查接管窗口。

C++异常后C资源怎样释放

C++异常后C资源怎样释放：run/report 的 check 抛出后，栈展开会调用 owner 的析构，再由删除器释放 C 句柄。删除器标 noexcept，不让清理异常覆盖原始错误；C 的 destroy 为 void 且不抛异常。构造尚未完成的对象不适用“对象析构会补救一切”，所以资源必须尽早交给已完成构造的 RAII 拥有者。

本例内部 mutex/join 不变式损坏会 abort，栈展开不能对此提供恢复保证。RAII 管理正常离开作用域和 C++ 异常，不保证进程被杀、崩溃或 abort 时执行清理。

C++借用get返回值可以保存多久

C++借用get返回值可以保存多久：owner.get 返回借用地址，不转移所有权；只在 owner 仍拥有对象且对象没有销毁时有效。release 则移交销毁责任并清空 owner，调用方若不立即建立新拥有者就泄漏。示例只用 get 进行同步调用，没有必要 release。

scan_report 借用 stdout 的 fd，不能把这个整数再装进会 close 的第二个拥有者。RAII 对象复制会造成双重清理，所以 unique_ptr 禁止复制；移动把唯一责任转移，原拥有者变空。借用指针不会因为移动自动延长对象生存期。

C++拥有句柄为什么仍然可能发生数据竞争

C++拥有句柄为什么仍然可能发生数据竞争：unique_ptr 解决生存期和唯一销毁，不自动提供同步。一个线程调用 run，另一个线程调用 report 或 destroy，仍违反句柄协议；内部锁只保护 worker 对 total 的更新，没有覆盖公开 API 的全部状态。

当前宿主只有一个调用线程，run 同步等待两个 worker 后返回，owner 离开作用域时它们已全部 join。若未来要异步调用，必须另行保证拥有者活到任务结束，并为所有共享状态建立同步，不能仅把 unique_ptr 换成 shared_ptr 就认为线程安全。

独立练习

接管raw之前插入可能抛异常的日志会怎样？能否用get产生第二个unique_ptr？

先写出状态和资源归属，再对照答案；这些是推演练习，没有执行示例。

参考解答与检查条件

创建已成功但没有拥有者时日志抛出会泄漏，应先立即接管。get只借用，第二个独占拥有者最终重复销毁；需要转移时使用移动。

资料与适用边界

2026-10-17 核对 Linux read 手册、write 手册、close 的平台差异、pthread_create、pthread_join 与 POSIX mutex 规范镜像。Linux 手册中的实现差异不直接推广为 macOS 实测结果。The Open Group 的 POSIX 页面本次抓取被拒绝，不记为已成功核读。线程依赖的目标表达参考 CMake 3.20 FindThreads，没有执行它来探测本机。

C++ 链接与拥有关系参照 cppreference language linkage、unique_ptr；中文核对 Microsoft extern 说明，仅引用语言链接概念，不套用其 Windows 编译开关。文章采用独立组织的边界与失败推演，外链用于溯源，必要答案已在正文。