《你真的了解C++吗》No.007：extern "C"——C++对C的妥协与名称修饰
导言：同根不同源的尴尬
C++ 自称是 C 的超集（大部分情况下），许多人理所当然地认为 C++ 代码可以直接调用 C 语言写的库，或者反之。然而，在二进制（链接）层面，C++ 和 C 简直是两种完全不同的语言。
如果你认为extern "C"只是为了让 C++ 编译器能编译 C 代码，或者不理解为什么链接器会报 “Undefined Reference” 错误即使函数名明明一样，那么你需要了解编译器幕后的“整容手术”——名称修饰。
一、根本矛盾：重载与唯一性
要在链接阶段找到一个函数，链接器（Linker）依赖的是符号名（Symbol Name）。
1. C 语言的世界：简单直接
在 C 语言中，函数名是唯一的。不能有两个名为foo的函数。因此，C 编译器处理函数void foo(int)时，生成的符号名通常就是简单的_foo（或者直接是foo，取决于平台）。
2. C++ 的世界：名称修饰 (Name Mangling)
C++ 支持函数重载。你可以定义void foo(int)，也可以定义void foo(double)。
如果 C++ 编译器也像 C 那样只生成_foo，链接器在看到两个_foo时就会疯掉——它不知道该链接哪一个。
为了解决这个问题，C++ 编译器会对函数名进行修饰（Mangle），将参数类型信息编码进符号名中。
void foo(int)\rightarrow 可能会变成_Z3fooi(3个字符的foo，参数int)void foo(double)\rightarrow 可能会变成_Z3food(3个字符的foo，参数double)
二、extern "C"的作用：停火协议
当你试图在 C++ 中调用一个 C 语言编译好的库函数（例如printf）时，问题出现了：
- C 库中，该函数的符号名是
printf。 - C++ 编译器看到
void printf(...)声明，试图寻找名为_Z6printfPKc（假设的修饰名）的符号。 - 结果：链接器报错：“Undefined Reference to
_Z6printfPKc”。
extern "C"的唯一作用，就是告诉 C++ 编译器：对于这就块代码，请“关闭”名称修饰，使用 C 语言的命名规则（即不修饰）来生成符号。
extern"C"{voidc_function(intx);// 编译器生成符号：_c_function，而不是 _Z10c_functioni}三、双向互操作的标准范式
在实际工程中，头文件通常需要既能被 C 编译器编译，又能被 C++ 编译器编译。这就诞生了经典的**“头文件卫士”**写法。
1. 标准写法
// my_c_api.h#ifdef__cplusplusextern"C"{// 只有 C++ 编译器能看懂 extern "C"#endifvoidmy_c_function(intx);intmy_math_add(inta,intb);#ifdef__cplusplus}#endif- 当 C 编译器包含此头文件：忽略
extern "C"，正常声明函数。 - 当 C++ 编译器包含此头文件：看到
extern "C"，知道这些函数是按 C 规则编译的，因此在生成调用指令时，去寻找未修饰的符号名。
2. C++ 调用 C
直接包含上述头文件即可。
3. C 调用 C++
这是比较棘手的地方。C 语言无法理解 C++ 的类、模板或虚函数。
如果想让 C 语言调用 C++ 库，必须在 C++ 端编写一个extern "C"的包装层 (Wrapper)。
// C++ 实现 (MyClass.cpp)classMyClass{public:voiddoWork(){}};// C 接口包装器extern"C"{void*create_my_class(){returnnewMyClass();}voiddo_work_wrapper(void*instance){static_cast<MyClass*>(instance)->doWork();}}四、extern "C"的限制与误区
- 它不是“变成 C 语言”：
在extern "C"块内部，你依然可以写 C++ 代码（如使用类、模板、new），只是这个块里声明的函数对外暴露的符号名变成了 C 风格。 - 不能重载：
你不能在extern "C"块内定义重载函数，因为 C 风格符号不支持重载。
extern"C"{voidfoo(int);voidfoo(double);// 错误！C语言命名规则下符号名冲突。}- 模板不可用：
模板的实例化高度依赖类型信息和名称修饰，因此模板不能声明为extern "C"。
总结：链接器的桥梁
extern "C"是 C++ 为了兼容庞大的 C 语言生态而做出的必要妥协。它不仅仅是一个语法糖，更是链接器协议的切换开关。
- 它解决了 C++名称修饰导致的符号不匹配问题。
- 它是混合编程（C/C++ Interop）的基石。
下一篇预告：既然我们一直在讨论编译器如何优化代码、如何修饰名称，那么有没有一种机制能阻止编译器的自作聪明？当硬件状态随时可能变化时，我们该怎么办？
➡️《你真的了解C++吗》No.008：volatile(The Volatile Keyword): 编译器优化的止步。
