为什么是extern＆＃34; C＆＃34;用于在运行时确定的共享对象库？

Question

1. 我在C ++程序中看到dlfcn库是动态使用的 链接到C ++用户选择的共享对象库 程序在运行时，以及调用所选的函数 通过dlsym()和dlfcn中的其他函数共享对象库。

   • 假设用户在运行时选择名为x.so的共享对象库。 x.so是从带有定义的cpp文件编译而来的 extern "C"中包含的函数。 cpp文件中的注释 说extern "C"的使用很重要，但没有进一步说明 解释，我想知道为什么？

   • 这里只涉及C ++代码并且没有涉及C代码是否正确？因此在混合C和C ++时extern "C"不一定仅 代码一起？

   • dlfcn库是否静态或动态链接到C ++程序是否与上述问题有关？

2. 现在比较一个更简单的情况，即共享对象库 早于运行时知道，并且是C ++程序的作者 在编译它之前在C ++程序中指定它而不使用dlfcn，然后 动态链接共享对象库和C ++程序 在运行时。在这种情况下，是`extern＆＃34; C＆＃34;还是有必要的 cpp文件被编译到共享对象库中？

感谢。

Answer 1

extern "C"更改链接，并影响名称重整。见What is name mangling, and how does it work?

如果没有它，编译对象中的导出名称通常会被破坏。这意味着它们不能在C中使用。它还意味着通过dlsym()查找它们需要使用损坏的名称。

  

这里只涉及C ++代码而不涉及C代码是否正确？那么在将C和C ++代码混合在一起时，不一定使用extern“C”吗？

目前尚不清楚你的意思。如果您正在编译C ++，那么此阶段只涉及C ++代码。如果您以任何方式链接到用C编写的模块，则涉及C.如果需要外部C库或程序链接到C ++定义的函数，则需要将它们声明为extern "C"。

  

dlfcn库是否静态或动态链接到C ++程序是否与上述问题有关？

否（或许你应该解释为什么你认为这可能很重要）。

  

现在比较简单的情况，其中共享对象库早于运行时知道，并且C ++程序的作者在编译它之前在C ++程序中指定它而不使用dlfcn，然后动态链接共享对象库和运行时的C ++程序。在这种情况下，在编译到共享对象库的cpp文件中仍然需要`extern“C”吗？

符号的声明链接必须在两个C ++模块中保持一致。当然，如果模块都是C ++，则可以删除extern "C"。但是，如果一个模块将符号声明为extern "C"，那么另一个模块也必须。