Static 媒体播放器的静态库与共享库

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

使用共享库的一个优点是，库可以独立于程序进行更新。在Windows上，这很少是一个优势，因为库将在应用程序旁边（由于没有官方C++ + ABI）。在Windows上，为了帮助减少DLL地狱和共享C库，我必须使用SxS，它不是一个很好的公民

至于静态库，我看到了一个很大的优势：链接时间优化。这些已经被ICC和VC++支持了很长一段时间，GCC为它们提供了一个分支。由于我可能在Windows上使用VC++，所以编译器的性能会有明显的提高（实际上，编译器）只是将C++转换成中间语言，所以编译器是“链接器”，它对代码有很好的了解，并且可以用这种方法来优化很多东西。这是我倾向的选择

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

---

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

我不完全确定您的“特定”案例是什么

如果你的“媒体播放器”是为一个众所周知的独特客户机（或一小部分客户机）设计的，在你的完全监督下，他会立即更新所有媒体播放器或任何给定的插件，那么我会选择静态库

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

对评论的回应：

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

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

---

我假设您在运行时加载它们，尽管如果可以称之为静态链接，但在任何其他情况下，您只需在每个插件上安装库，而不会“共享”。

这是一个开源播放器。动态库如何帮助更新？如果使用静态库，如何更新您的插件“将xxx库更新为最新版本"破坏我的应用程序？我想反过来说。静态库和共享库一样向后兼容，因为它们是从同一个源生成的。使用较新版本所需要做的就是重新编译库并针对它们重新链接-这不是一个真正的问题。我看不出地址空间偏移对我有什么影响，因为插件将有一个回调设计（也就是说，它们依赖于应用程序告诉它们做一些事情），唯一常见的依赖项是Qt。也许我会将所有通用应用程序代码导出到一个共享库中，以便插件可以使用它，但在这种情况下，我不觉得这真的有用。