cppfront 不是 C++2 官方实现，而是将 Herb Sutter 提出的实验性 cpp2 语法转换为标准 C++20/23 的源码到源码翻译器，不提供新语义、不改 ABI、需配合 clang/g++ 二次编译，目前仅适用于语法验证与教学演示。
cppfront 不是 C++2 的官方实现，也不是编译器，它只是一个实验性前端，把 cpp2 语法（Herb Sutter 提出的“C++2”概念，非 ISO 标准）翻译成标准 C++20/23 代码。你无法用它“编译运行 C++2”，只能生成可被 clang/g++ 编译的 C++。
cppfront 本质是源码到源码的转换器
它不带运行时、不改 ABI、不提供新语义——所有 cpp2 特性（如 !int 非空指针、[[nodiscard]] 级别的契约语法、enum class 的隐式作用域规则等）都靠宏、模板、static_assert 和现代 C++ 模式模拟出来。生成的 C++ 代码可读性差、调试困难，且很多特性目前只是骨架（比如 contract 声明尚未落地为可执行检查）。
实操建议：
- 只在明确想验证某个
cpp2语法能否转出合理 C++ 时使用，别把它当开发工具链 - 必须搭配 C++20+ 编译器（如
clang++-17 -std=c++20）二次编译生成的.cpp文件 - 原始
.cpp2文件里不能混用未被 cppfront 支持的语法（例如if constexpr在 cpp2 中写法不同，但 cppfront 当前不处理它）
安装与基本流程：不是 apt install cppfront
cppfront 没有预编译包，必须从源码构建。它依赖 C++20 编译器和 CMake，且构建过程不稳定（截至 2024 年中，master 分支常因 Clang AST API 变更而 break）。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 克隆指定稳定 commit（比如
8a9f3c1，对应 2023 年底的 demo 版本），别用最新 master -
cmake -B build -DCMAKE_CXX_STANDARD=20后，用make -C build构建，而非make install（它不安装到系统路径） - 运行时需显式指定输出目录：
./build/cppfront input.cpp2 -o generated/
，否则默认输出到当前目录且不报错 - 生成的文件名是
input.cpp2.cpp，不是input.cpp——漏看后缀会导致g++报 “not a C++ file”
常见转换失败原因：语法糖 vs 实际支持
cppfront 对 cpp2 语法的支持极不完整。例如：
-
!T*（非空指针）会被转成带assert(p)的包装类，但若T是模板参数且未约束，会触发 C++ 模板实例化错误，而非 cppfront 报错 -
[[expects: x > 0]]这类契约语法目前仅保留注释，不生成任何检查代码（文档称 “experimental and incomplete”） -
enum class E { a, b };在 cpp2 中允许直接写a，但 cppfront 不做作用域注入，仍需E::a - 所有
auto推导在转换后变成显式类型，但若推导依赖未定义符号（如未 include 的头文件），错误会出现在第二阶段（g++ 编译时），而非 cppfront 阶段
调试生成代码比写 cpp2 更耗时
cppfront 输出的 C++ 代码大量使用嵌套模板别名、立即调用 lambda、constexpr if 展开，且无格式化。一个简单的 !int* 参数可能展开为 50 行带 __cpp2_detail 前缀的模板代码。
实操建议：
- 用
clang++ -std=c++20 -Xclang -ast-dump -fsyntax-only查看生成代码的 AST，比肉眼读更快定位问题来源 - 对关键函数，手动删减 cppfront 输出中无关的模板层，保留核心逻辑再测试
- 不要在 CI 中引入 cppfront——它的构建失败率高、输出不可控、无版本锁定机制
真正卡住人的从来不是怎么写 cpp2 语法，而是搞清哪部分被转了、哪部分被跳过、哪部分转出来根本没法编译。它目前只适合语言设计讨论或教学演示，离实用还有很长一段距离。
