C与C++构造兼容性边界：失效代码的技术根因与迁移策略

C 与 C++ 的兼容性边界并非静态。C23 和 C++20 的演进使部分历史差异缩小，但核心对象模型的分歧依然存在。对于需要将遗留 C 代码迁移到 C++ 环境的工程团队而言，理解这些构造层面的技术根因比单纯记忆 "C++ 不是 C 的超集" 这一论断更具实践价值。

void * 隐式转换：类型系统的第一道关卡

C 语言允许从void*到任何对象指针的隐式转换，这使得malloc的调用模式在 C 中极为简洁：

int* values = malloc(100 * sizeof *values);

这段代码在 C++ 编译器下会触发类型错误，因为 C++ 要求显式转换。表面看这只是语法差异，但深层问题在于 C++ 的对象生命周期模型。C++20 引入了隐式对象创建规则，对于隐式生命周期类型（如平凡聚合体），malloc分配的存储在某些场景下可以自动开始对象生命周期，但这不适用于非平凡类型。

// C++中安全的低层写法
void* storage = ::operator new(sizeof(std::string));
auto* s = new (storage) std::string("hello");
std::destroy_at(s);
::operator delete(storage);

关键洞察在于：C 的malloc仅分配存储，C++ 的new同时处理存储分配与对象构造。迁移时应区分 "存储" 与 "构造" 两个概念，对非平凡类型必须使用 placement new 显式建立对象生命周期。

指定初始化器：语法相似性背后的语义鸿沟

C++20 引入了指定初始化器，这常被误解为 "C99 特性终于进入 C++"。实际上 C++ 的版本有严格限制：设计器必须按声明顺序命名直接非静态数据成员，不支持数组设计器、嵌套设计器，也不允许混合位置与指定子句。

// 合法的C代码，非法的C++
struct Triple { int first, second, third; };
struct Triple t = { 1, .third = 3 };  // C允许混合，C++20拒绝

int table[4] = { [2] = 99 };  // C允许数组设计器

C++ 的这些限制源于其更复杂的对象模型 —— 构造函数、析构函数、默认成员初始化器以及可观察的初始化顺序。C 风格的自由度会与 C++ 的类不变量机制产生冲突。迁移策略很明确：在 C++ 代码中使用指定初始化器时，仅用于纯聚合体的直接成员初始化，且严格遵循声明顺序。

枚举类型系统：从整数回退到类型安全

C 与 C++ 在枚举处理上的差异体现了两种语言的设计哲学分歧。C17 中枚举器常量具有整数类型，枚举对象可自由参与整数转换；C23 引入了固定底层类型，但转换规则仍比 C++ 宽松。

enum Mode { off = 0, on = 1 };
int x = on;        // C++允许：枚举到int
Mode m = 1;        // C++拒绝：int到枚举需显式转换
Mode m2 = static_cast<Mode>(1);  // 正确做法

C++ 的enum class提供了更强的类型隔离，枚举值不会隐式扩散到 surrounding scope，也不会隐式转换为整数。迁移建议：面向 C++ 的 API 优先使用enum class，仅在 C ABI 兼容或需要旧式枚举行为时使用 plain enum。

函数原型与空参数列表：C23 的收敛

历史上，void f()在 C 与 C++ 中有不同含义。C++ 中它明确表示无参数函数；C17 及之前版本中它不提供原型，调用时参数检查宽松。C23 通过 N2841 提案消除了这一差异：无参数类型列表的函数声明符现在表现为void原型。

这一变化带来迁移上的微妙考量：旧 C 代码可能在 C17 模式下编译通过但在 C23 模式下失败。对于需要跨语言兼容的头文件，显式书写void f(void)仍然是最稳妥的做法。

const_cast 与未定义行为边界

C++ 强制要求显式丢弃const限定，但这只是编译时检查。一个常见陷阱是认为const_cast赋予了写入权限：

const int x = 100;
int* p = const_cast<int*>(&x);
*p = 101;  // 未定义行为：x实际为const对象

只有当底层对象本身不是const时，通过const_cast获得的写入才是定义行为。迁移遗留代码时，应将const_cast限制在边界层 —— 例如调用承诺不修改却只接受char*的 C API 时 —— 并配以清晰的文档说明。

可落地的迁移检查清单

基于上述技术根因，迁移 C 代码到 C++ 时可遵循以下清单：

1. 标注语言模式：讨论兼容性时必须指明具体标准版本（C17/C23/C++17/C++20/C++23），"有效 C" 的表述已不足够精确。

2. 隔离 ABI 边界：保留 C 布局在接口边界，内部立即转换为 C++ 类型系统表达。柔性数组成员、可变长度结构等 C 惯用法应封装在适配层。

3. 区分存储与构造：使用malloc的代码需审计对象类型。平凡类型可考虑std::make_unique替代；非平凡类型必须使用 placement new 或标准容器。

4. 显式处理类型转换：void*转换、const丢弃、枚举到整数的转换都应显式书写，避免依赖隐式规则。

5. 限制编译器扩展：restrict、柔性数组成员等扩展应隔离在具名、可测试的移植边界之后。

C 与 C++ 的构造兼容性是一个动态演进的领域。C23 和 C++20 的更新确实缩小了部分历史差异，但两种语言在对象模型、初始化语义和类型系统上的根本分歧决定了 "合法 C 代码在 C++ 下失效" 的场景仍将长期存在。理解这些差异的技术根因，而非仅记忆症状，是构建可维护跨语言代码库的基础。

参考来源

• Josh Lospinoso, "C Constructs That Still Don't Work in C++ — and a Few That Changed", 2026
• WG14 N2841, "No function declarators without prototypes", C23 提案

compilers