结合 C++ 和 C - #ifdef __cplusplus 如何工作？

我正在从事一个有很多遗产的项目C代码。我们已经开始使用 C++ 进行编写，目的是最终转换遗留代码。我有点困惑如何C和C++交互。我明白，通过包装C代码与extern "C"C++编译器不会破坏C代码的名称，但我不完全确定如何实现它。

所以，在每个的顶部C头文件（在包含防护之后），我们有

#ifdef __cplusplus
extern "C" {
#endif

在底部，我们写

#ifdef __cplusplus
}
#endif

在两者之间，我们拥有所有的包含、类型定义和函数原型。我有几个问题，看看我是否理解正确：

1. 如果我有一个 C++ 文件 A.hh 包括一个C头文件B.h， 包括另一个C头文件C.h, 这是如何运作的？我觉得 当编译器进入B.h时，__cplusplus将被定义，所以它 将用以下内容包装代码extern "C" (and __cplusplus不会是 定义在该块内）。所以， 当它进入C.h时，__cplusplus将不会被定义 并且代码不会被包装在extern "C"。它是否正确？

2. 有什么问题吗 包装一段代码extern "C" { extern "C" { .. } }？ 第二个会怎样extern "C" do?

3. 我们不会将此包装器放在 .c 文件周围，而是将其放在 .h 文件周围。那么，如果函数没有原型会发生什么？编译器是否认为它是一个 C++ 函数？

4. 我们也在使用一些第三方 代码是写在C，并且确实 没有这种包装 它。任何时候我包含标题 从那个图书馆，我一直在放 一个extern "C"围绕#include。 这是正确的处理方式吗 那？

5. 最后，这个设置是个好主意吗？ 还有什么我们应该做的吗？ 我们要混合C和C++ 在可预见的未来，我 想要确保我们涵盖了所有内容 我们的基地。

extern "C"并没有真正改变编译器读取代码的方式。如果您的代码位于 .c 文件中，它将被编译为 C，如果它位于 .cpp 文件中，它将被编译为 C++（除非您对配置做了一些奇怪的事情）。

What extern "C"确实是影响联动。 C++ 函数在编译时，其名称会被破坏——这就是重载成为可能的原因。函数名称会根据参数的类型和数量进行修改，因此两个同名的函数将具有不同的符号名称。

里面的代码extern "C"仍然是C++代码。在外部“C”块中可以执行的操作有一些限制，但它们都与链接有关。您无法定义任何无法使用 C 链接构建的新符号。例如，这意味着没有类或模板。

extern "C"块嵌套得很好。还有extern "C++"如果你发现自己绝望地陷入困境extern "C"地区，但从清洁角度来看这并不是一个好主意。

现在，特别是关于您的编号问题：

关于 #1： __cplusplus 将保留在extern "C"块。不过，这并不重要，因为块应该整齐地嵌套。

关于 #2：__cplusplus 将为通过 C++ 编译器运行的任何编译单元定义。一般来说，这意味着 .cpp 文件以及该 .cpp 文件包含的任何文件。如果不同的编译单元包含相同的 .h（或 .hh 或 .hpp 或其他），则它们可能在不同时间被解释为 C 或 C++。如果您希望 .h 文件中的原型引用 C 符号名称，那么它们必须具有extern "C"当被解释为 C++ 时，它们不应该有extern "C"当被解释为 C 时——因此#ifdef __cplusplus检查。

回答你的问题#3：如果没有原型的函数位于 .cpp 文件中而不是在 .cpp 文件中，则它们将具有 C++ 链接extern "C"堵塞。不过，这很好，因为如果它没有原型，则只能由同一文件中的其他函数调用，然后您通常不关心链接是什么样的，因为您不打算拥有该函数无论如何，都会被同一编译单元之外的任何东西调用。

对于#4，你已经完全明白了。如果您要包含具有 C 链接的代码的标头（例如由 C 编译器编译的代码），那么您必须extern "C"标头——这样您就可以与库链接。 （否则，您的链接器将寻找名称类似于_Z1hic当你在寻找的时候void h(int, char)

5：这种混合是使用的常见原因extern "C"，我不认为这样做有什么问题——只要确保你明白你在做什么。