5

通过插件。
我们的意思是一个加载 vi 的库，dlopen()它的符号通过dlsym()（不是由运行时系统动态加载的标准分片库）解析。

参考http://www.isotton.com/howtos/C++-dlopen-mini-HOWTO/。该文档最后一次更新是在 2006 年。它建议使用extern "C"来防止函数名称的混淆，以便dlsym可以相对轻松地找到它的函数。

这仍然与动态库相关吗？在我的特殊情况下，我正在尝试使用 libtool 在 OSX 上创建一个动态库。也许使用__attribute__ ((constructor))更时髦和现代，我发现推荐的做法几乎没有成功。

4

2 回答 2

5

我很确定extern "C"这仍然是从 C++ 代码中导出未损坏函数的最佳方式。在多个平台上使用它没有问题。

于 2012-01-20T17:23:39.077 回答
1

运行时插件

如果您计划手动加载库dlopen()并用于dlsym()检索和解析函数/对象，那么使用 extern "C" 名称会变得容易得多。名字混乱是一件痛苦的事。

因此，如果您想要更轻松的可移植性/可用性，请使用 C (extern "C") interface。

但是您应该考虑暴露 C (extern "C") 接口的缺点。
这意味着您不能直接通过接口公开任何 C++ 对象。因此，您最初会失去很多功能，例如 RAII。您应该通过编写额外的包装器调用来包装对 C 接口的调用来弥补这一点

普通共享库

编辑：原始答案：

最初的问题是关于共享库的（只有通过评论我们才发现它是关于插件共享库的）。

所以名字是不可取的。
如果编译器/运行时正在解析符号，这不是问题。

你打算使用多个编译器吗？因为这是我可以看到导出 C 接口的唯一原因（因为不同的 C++ 编译器经常使用不同的 ABI）。

如果您使用相同的编译器，那么为什么不使用 C++ 接口。
就个人而言，在任何给定平台上，我只使用一个编译器，并且只使用该平台上的共享对象。如果编译器升级，发生了更大的事情，无论如何我都会重新构建我的所有库。

于 2012-01-20T17:36:16.720 回答