仅仅通过在外部“C”中包装，并不能使任何C标头与C++兼容。当C标头中的标识符与C++关键字冲突时，C++编译器会对此进行投诉。

例如，我看到以下代码在g++中失败：

extern "C" {
struct method {
    int virtual;
};
}

Kinda是有道理的，但在将C代码移植到C++时需要记住。

extern“C”使C++中的函数名具有C链接（编译器不会损坏该名称），以便客户端C代码可以使用仅包含函数声明的C兼容头文件链接到（使用）您的函数。函数定义包含在二进制格式（由C++编译器编译）中，然后客户端C链接器将使用C名称链接到该格式。

由于C++有函数名的重载，而C没有，所以C++编译器不能仅将函数名用作链接到的唯一id，因此它通过添加有关参数的信息来破坏名称。C编译器不需要更改名称，因为您不能重载C中的函数名。当您声明函数在C++中具有外部“C”链接时，C++编译器不会将参数/参数类型信息添加到用于链接的名称中。

正如您所知，您可以显式指定每个单独声明/定义的外部“C”链接，或使用块将声明/定义序列分组以具有特定链接：

extern "C" void foo(int);
extern "C"
{
   void g(char);
   int i;
}

如果您关心技术细节，请参见C++03标准第7.5节，这里有一个简短的总结（重点是外部“C”）：

外部“C”是链接规范每个编译器都需要提供“C”链接链接规范只能出现在命名空间范围内所有函数类型、函数名和变量名都有语言链接参见Richard的评论：只有具有外部链接的函数名和函数名才有语言链接具有不同语言链接的两种函数类型是不同的类型，即使在其他方面相同连杆规格嵌套，内部规格决定最终连杆类成员忽略外部“C”最多一个具有特定名称的函数可以具有“C”链接（无论名称空间如何）外部“C”强制一个函数具有外部链接（不能使其成为静态的）参见Richard的评论：外部内部的静态“C”是有效的；这样声明的实体具有内部链接，因此没有语言链接从C++到用其他语言定义的对象以及从其他语言到用C++定义的对象的链接是由实现定义的，并且依赖于语言。只有当两种语言实现的对象布局策略足够相似时，才能实现这种链接

它以这样一种方式更改函数的链接，即该函数可以从C调用。实际上，这意味着函数名不会被破坏。

我只是想添加一些信息，因为我还没有看到它发布。

您将经常看到C头中的代码，如下所示：

#ifdef __cplusplus
extern "C" {
#endif

// all of your legacy C code here

#ifdef __cplusplus
}
#endif

这实现的是，它允许您在C++代码中使用C头文件，因为宏__cplusplus将被定义。但是您也可以将它与遗留的C代码一起使用，因为宏没有定义，所以它不会看到唯一的C++构造。

虽然，我也见过C++代码，例如：

extern "C" {
#include "legacy_C_header.h"
}

我想这也能完成同样的事情。

不知道哪种方式更好，但我都见过。

当混合使用C和C++时（即a.从C++调用C函数；b.从C调用C++函数），C++名称混乱会导致链接问题。从技术上讲，只有当被调用函数已经使用相应的编译器编译成二进制（很可能是*.a库文件）时，才会出现此问题。

因此，我们需要使用外部“C”来禁用C++中的名称篡改。

最近，gcc似乎也支持名称篡改。即使在外部“c”中，如果使用类或重载，它也会自动损坏。

#include <stdio.h>
extern "C"{


struct myint{
    int i;
};

struct myint2
{
    int a;
    myint2(int a): a(a) {};
    operator myint() const {return myint{a};}
};

}

void f1(myint i){
    printf("%d", i.i);
}

int main(){
    myint2 a(1);
    f1(a);
}

我甚至使用了许多cpp功能。但代码编译和运行正常。如果你nm，你可以看到main没有损坏，但myint是损坏的。