媒体播放器的静态与共享库 [关闭]

Question

我不会详细介绍“媒体播放器”部分，除非它显然会使用插件，这将是一个在运行时加载的简单动态库。现在，我可以将这些插件动态链接到它们的依赖项，或者我可以静态链接它们。两者都有其优点和缺点 - 我在这里不计算 Linux，因为它将使用共享库。

我看到使用共享库的唯一优势是库可以独立于程序进行更新。在 Windows 上，这很少是一个优势，因为该库将在使用它的应用程序旁边（感谢没有官方的 C++ ABI）。在 Windows 上，为了帮助减少 DLL 地狱并共享 C 库，我将不得不使用 SxS，这不是一个非常好的公民。

对于静态库，我看到了一大优势：链接时优化。 ICC 和 VC++ 已经支持它们很长一段时间了，GCC 也为它们提供了一个分支。由于我可能会在 Windows 上使用 VC++，因此编译器（嗯，实际的“编译器”只是将 C++ 转换为中间语言，所以这里的编译器是“链接器”）对代码并且可以通过这种方式优化很多东西。这是我倾向于的选项。

我的问题是，在我的具体案例中，哪一个是最好的？

没有其他应用程序使用它们的问题，因为在这个问题中我不计算 Linux（尽管我不了解 OS X）或多个实例（谁运行同一个媒体播放器两次？），二进制兼容性（因为我将随应用程序分发所有内容）或易于更新（在 Windows 上，我将使用非常高效的二进制差异修补程序来分发更新）。

Answer 1

我不完全确定您的“具体”案例是什么。

如果您的“媒体播放器”是为知名的独特客户（或少数客户）设计的，他们将在您的完全监督下一次更新所有媒体播放器或任何给定插件，那么我将选择静态图书馆。

如果不是这样，我会选择动态库。优化是好的，但不如客户/用户满意度好。没有什么比将你的 xxx 库更新到最新版本更糟糕的了，所有突然的事情都停止工作了。如果您无法控制更新的时间和方式，请尽可能灵活。

回复评论：

通常动态库向后兼容次要版本，而静态链接可能依赖于具体版本，如果您尝试将其链接到另一个版本，则会中断。使用动态链接，只要您使用的调用不变，您的程序甚至可以工作，而静态链接可能取决于库中函数偏移量的变化。

例如，静态库可能会在运行时以静态偏移量加载到进程的地址空间中。当然，知道这个偏移量可以进行某些优化，但是如果您更新库，那么您要么使用该库更新所有插件，要么可能未更新的插件将无法工作（因为函数偏移量很可能已经改变）。

我假设您在运行时加载它们，尽管如果可以将其命名为静态链接，那么在任何其他情况下，您只会在每个插件上拥有库，并且不会有“共享”。