既然C++编译器支持编译C代码，为何还要使用extern "C"做C外部链接？

1. 核心根源：C与C++的名字修饰（Name Mangling）规则不同 #

C语言不支持函数重载、命名空间等特性，编译器编译C函数时，生成的符号名就是原始的函数名，比如my_strlen函数编译后的符号就是my_strlen（部分平台会加下划线前缀，规则统一）。
而C为了支持重载、命名空间、模板等特性，编译器会把函数的参数类型、所属命名空间、模板参数等信息编码到符号名里，比如同是my_strlen函数，C编译后生成的符号名可能是_Z9my_strlenPKc，和C的生成规则完全不同。
extern "C"的作用就是告诉C编译器：**这部分函数按照C的规则生成/匹配符号名，不要做C风格的名字修饰**。

你测试时删掉extern "C"后全用g编译能正常运行，是因为此时my_string.c也被当做C代码编译，两个编译单元的符号名都是按C规则生成的，自然可以匹配。但这已经不是「C代码给C调用」的场景了，属于所有代码统一按C++编译的场景。
你可以尝试以下操作复现错误，就能直观感受到必要性：

1. 用gcc编译C代码生成目标文件：gcc -c my_string.c
2. 删掉头文件中的extern "C"相关代码
3. 用g编译C代码并链接之前生成的目标文件：g++ main.cxx my_string.o -o prog
   此时一定会报undefined reference to 'my_strlen(char const*)'的链接错误，原因就是C在找修饰后的C风格符号，而目标文件里只有C风格的原始符号，二者无法匹配。

2. 为什么不直接全用C++编译器编译所有C代码？ #

实际开发中很少这么做，核心原因有三个：

• 语法不兼容：C和C并不是完全的上下兼容关系，很多合法的C语法在C中是错误的。比如C允许void*直接赋值给其他指针类型无需强转、支持变长数组、支持隐式函数声明、允许结构体标记和全局变量重名等，这些特性用g++编译都会直接报错，纯C代码用C编译器编译才能保证语法兼容性。
• ABI兼容性差：C和C的应用二进制接口（ABI）存在大量差异，包括函数调用约定、结构体内存布局、异常处理规则、运行时依赖等。用gcc编译的纯C库可以被所有C环境直接调用，加了extern "C"后也可以被C调用，适用范围远大于用g++编译C代码生成的库。
• 第三方依赖限制：绝大多数系统内置C库、开源C依赖都是用C编译器编译发布的，你不可能把所有依赖都用C++编译器重新编译一遍，调用这些现成的C库时，就必须通过extern "C"声明来匹配符号。

3. extern "C"的核心价值 #

它的本质是实现C和C++的双向跨语言链接：

• 让C++代码可以正常调用C编译器生成的目标文件/静态库/动态库
• 让C++编写的代码可以导出C风格的符号，供纯C环境调用

内容的提问来源于stack exchange，提问作者Itachi Uchiwa