c++oding="utf-8" ?>
必须将.m文件改为.mm后缀启用objective-c++模式，并在头文件中隔离c++类型（如用opaque pointer或c函数封装），同时确保链接libc++且明确管理arc与c++对象的生命周期。
如何让 .m 文件正确调用 C++ 类
Objective-C 的 .m 文件默认不支持 C++ 语法，直接 #include C++ 头文件或使用 std::string 会报错：「Unknown type name 'std'」或「Expected a type」。根本原因是编译器把 .m 当作纯 Objective-C 源码处理，跳过了 C++ 解析阶段。
必须把文件后缀改为 .mm，Xcode 才会启用 Objective-C++ 模式（即 Clang 的 -x objective-c++ 模式）。注意：只改后缀不够——如果该文件被其他 .m 文件 #import，而那个 .m 又试图访问你暴露的 C++ 类型（比如返回 std::vector），依然会崩。所以接口层必须做类型隔离：
- 对外头文件（
.h）里不能出现任何 C++ 类型：避免std::、模板、类定义、引用（&）、指针（*）等；可用void *或自定义 opaque pointer（如typedef struct MyCppClass *MyCppClassRef;）做前向声明 - C++ 实现逻辑全部收进
.mm文件内部，头文件只暴露 C 风格函数或 Objective-C 接口（如- (NSString *)processInput:(NSString *)s;） - 若需传递复杂数据，用 Foundation 类桥接：
std::string→NSString *，std::vector<int></int>→NSArray<nsnumber> *</nsnumber>
在 .h 中安全声明 C++ 对象的三种方式
头文件是混编最易出错的地方。常见错误是写 class MyClass { ... }; 或 extern std::map<int std::string> gCache;</int>，导致所有 import 它的 .m 文件编译失败。
可行方案只有以下三种，按推荐顺序排列：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
Opaque pointer（最推荐）：
typedef struct MyCppImpl *MyCppImplRef;放.h；在.mm里用struct MyCppImpl { std::string data; };实现；所有方法参数/返回值只用MyCppImplRef -
C 函数封装：在
.h中声明void mycpp_do_work(const char *input);，实现放在.mm，内部调用 C++ 逻辑 -
Objective-C wrapper 类：定义
@interface MyCppWrapper : NSObject，其.h不暴露 C++ 成员；.mm中用@implementation内嵌 C++ 对象（如std::unique_ptr<realcppclass> _impl;</realcppclass>）
链接 C++ 标准库时遇到 “undefined symbol” 怎么办
即使 .mm 编译通过，运行时可能崩溃并提示类似 __ZStlsIcSt11char_traitsIcESaIcEERSt13basic_ostreamIT_T0_ES7_RKSt7__cxx1112basic_stringIS4_S6_T1_E 这样的符号未定义错误——这是 C++ ABI 符号，说明链接器没找到 libc++。
Xcode 默认对 iOS target 使用 libc++，但某些旧工程或手动配置过 Build Settings 的项目可能仍设为 libstdc++（已废弃）或未显式指定：
- 检查
Build Settings → C++ Standard Library，必须设为libc++（不是libstdc++） - 确认
Build Settings → Other Linker Flags包含-lc++（Xcode 通常自动加，但跨静态库时可能漏） - 若用到 C++17 特性（如
std::optional），还需设C++ Language Dialect为C++17或更高 - 静态库（.a）若含 C++ 代码，必须确保其构建时也用了
libc++，否则主工程链接会失败
ARC 与 C++ 对象生命周期冲突怎么处理
Objective-C++ 混编中最大的隐性坑是内存管理错位：ARC 管不到 C++ 对象，而 C++ 析构又不能自动触发 Objective-C 对象释放。典型场景是 C++ 类持有 id 或 NSObject * 强引用，或 Objective-C 类成员是 C++ 对象但未定义析构逻辑。
关键原则：谁分配，谁负责清理，且边界清晰：
- C++ 对象在
.mm中 new 出来，就必须在dealloc（Objective-C）或析构函数（C++ wrapper 类）里 delete；ARC 不会帮你做这事 - 避免在 C++ 类中直接存储
id：改用__unsafe_unretained id或CFTypeRef+ CFRetain/CFRelease 手动管理 - 若 C++ 对象需回调 Objective-C 方法，用 block 或 delegate 模式，block 要注意循环引用（用
__weak typeof(self) weakSelf = self;） - std::shared_ptr 等智能指针可安全持有 C++ 资源，但不能直接 hold Objective-C 对象（除非转成 CFTypeRef 并配对 CFRetain）
混编不是简单改后缀就能跑通的事，核心在于头文件契约、链接器配置、内存责任划分这三层必须同时对齐。任意一层松动，都会在编译期或运行时突然报错，而且错误信息往往和真实问题隔了两层。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
