一、名字修饰：C与C++的“语言墙”
说实话，我第一次遇到C和C++链接失败的问题时，整个人是懵的。明明函数声明都写对了，编译也通过了，链接器却报“未定义引用”。后来我才知道，这背后是名字修饰在作怪。
1.1 什么是名字修饰？
C++支持函数重载，同名函数可以有不同的参数列表。但链接器只认符号名，不认参数类型。为了解决这个矛盾，C++编译器会对函数名进行“修饰”——把函数名和参数类型信息编码成一个新的符号名。
举个例子：
// C++ 代码
int add(int a, int b);
double add(double a, double b);经过GCC的C++编译器处理后，这两个函数在目标文件中的符号名可能是：
_Z3addii // int add(int, int)
_Z3adddd // double add(double, double)而C编译器不会做任何修饰，直接生成 add 这个符号。
关键点：C编译器不修饰名字，C++编译器会修饰。这就是C和C++链接时冲突的根源。
1.2 不同编译器的修饰规则
不同编译器的修饰规则完全不同。我在项目中遇到过从GCC切换到MSVC时，所有C++库都得重新编译——因为符号名对不上。
| 编译器 | 修饰示例（int add(int, int)） | 特点 |
|---|---|---|
| GCC (Linux) | _Z3addii |
以_Z开头，后跟函数名长度和参数类型缩写 |
| MSVC (Windows) | ?add@@YAHHH@Z |
以?开头，包含返回类型和参数信息 |
| Clang | 与GCC兼容 | 基本遵循Itanium C++ ABI |
小技巧：用 nm 命令可以查看目标文件中的符号名。比如 nm myobject.o | grep add，你就能看到修饰后的样子。
二、extern "C"：打通C和C++的桥梁
3.1 基本用法
extern "C" 告诉C++编译器：这段代码请用C的链接方式处理。说白了，就是让C++编译器不要对函数名做修饰。
// C++ 代码
extern "C" {
void c_function(int x);
int another_c_func(double y);
}
// 或者单函数声明
extern "C" void c_function(int x);加了 extern "C" 后，c_function 在目标文件中的符号名就是 c_function，而不是 _Z11c_functioni。
3.2 头文件中的标准写法
我建议在头文件中这样写，这样C和C++都能用：
#ifdef __cplusplus
extern "C" {
#endif
void c_function(int x);
int another_c_func(double y);
#ifdef __cplusplus
}
#endif为什么这么写？__cplusplus 是C++编译器预定义的宏。C编译器没有这个宏，所以不会看到 extern "C"——C编译器本来就不认识这玩意儿。
注意：extern "C" 只能用于函数声明和全局变量，不能用于函数定义内部。也不能用于C++特有的特性，比如重载、模板、命名空间等。
3.3 常见陷阱
我曾经在项目中犯过一个低级错误：在C++文件中定义了一个函数，用 extern "C" 声明，但函数体内却用了C++标准库的 std::vector。结果链接是成功了，运行时却崩溃了——因为C代码调用这个函数时，栈布局和异常处理机制完全不匹配。
记住：extern "C" 只改变链接方式，不改变调用约定和ABI。函数内部如果用了C++特性，仍然需要C++运行时支持。
三、ABI兼容性：链接的底层契约
3.1 什么是ABI？
ABI（Application Binary Interface）是二进制层面的接口规范。它规定了：
- 函数参数如何传递（寄存器还是栈）
- 返回值如何返回
- 结构体的内存布局和对齐方式
- 异常处理机制
- 虚函数表的结构
说白了，ABI就是编译器生成二进制代码时必须遵守的“游戏规则”。
3.2 C与C++的ABI差异
C和C++的ABI在很多方面不同。我举个例子：
// C 代码
struct Point {
int x;
double y;
};
// C++ 代码
struct Point {
int x;
double y;
void print(); // C++特有：成员函数
};C编译器生成的 Point 结构体，大小就是 sizeof(int) + sizeof(double) + 可能的填充。但C++编译器可能会插入虚函数表指针（如果有虚函数），或者调整成员顺序。
核心原则：C和C++之间传递数据，只能用C兼容的结构体（POD类型）。不要传递C++对象、引用、异常等。
3.3 保持ABI兼容的实践
我在做跨语言调用时，总结了几条铁律：
- 接口函数用
extern "C"：确保符号名不被修饰 - 参数类型用C基本类型：int、double、char* 等，不要用C++的string、vector
- 结构体用POD类型：没有构造函数、析构函数、虚函数
- 不要跨语言传递指针所有权：谁分配谁释放
- 统一调用约定：Windows上注意
__cdecl和__stdcall的区别
// 安全的C/C++接口示例
#ifdef __cplusplus
extern "C" {
#endif
// POD结构体
typedef struct {
int id;
double value;
char name[64];
} DataPoint;
// 纯C接口
DataPoint* create_data_point(int id, double value, const char* name);
void destroy_data_point(DataPoint* dp);
void print_data_point(const DataPoint* dp);
#ifdef __cplusplus
}
#endif四、知识体系总览
下面这张图总结了C与C++链接的核心逻辑：
五、避坑指南
最后分享几个我踩过的坑：
坑1：我曾经在C++库中导出一个类，用 extern "C" 包装了构造函数和成员函数。结果C代码调用时，因为不知道虚函数表的存在，直接内存访问越界。教训：不要试图用 extern "C" 导出C++类。
坑2：在Windows上用MSVC编译的库，链接到GCC编译的程序。两个编译器对 long 类型的理解不同——MSVC中 long 是4字节，GCC在64位Linux上是8字节。教训：跨编译器链接时，用 int32_t、int64_t 等明确大小的类型。
建议：如果你在写一个需要被C和C++同时调用的库，从一开始就用纯C接口设计。内部可以用C++实现，但对外暴露的接口必须是C兼容的。这样最省心。
嗯，关于C与C++链接的核心机制，就讲到这里。记住一句话：名字修饰是表象，ABI兼容性是本质。extern "C" 是桥梁，但桥的两端必须遵守同样的交通规则。
公众号:蓝海资料掘金营，微信deep3321