我不打算详细介绍“媒体播放器”部分，除了它显然会使用插件，这将是一个在运行时加载的简单动态库。现在，我可以动态地将这些插件链接到它们的依赖项，或者我可以静态地链接它们。两者都有它们的优点和缺点 - 我在这里不算Linux，因为它将使用共享库。
我看到使用共享库的唯一优势是可以独立于程序更新库。在Windows上，这很少有优势，因为库将在使用它的应用程序旁边（由于没有正式的C ++ ABI）。在Windows上，为了帮助减少DLL地狱并共享C库，我将不得不使用SxS，这不是一个非常好的公民。
对于静态库，我看到一个很大的优势：链接时优化。 ICC和VC ++已经支持了很长一段时间，GCC为他们提供了一个分支。由于我可能会在Windows上使用VC ++，因此编译器会有明显的性能提升（好吧，实际的“编译器”只是将C ++转换为中间语言，因此这里的编译器就是“链接器”）具有完美的知识。代码，可以通过这种方式优化大量的东西。这是我倾向于的选择。
我的问题是，在我的具体案例中哪一个最好？
不用担心其他应用程序使用它们，因为我在这个问题上不算Linux（虽然我不知道OS X）或多个实例（无论如何都运行相同的媒体播放器两次？），二进制兼容性（因为我将使用应用程序分发所有内容）或易于更新（在Windows上我将使用非常有效的二进制差异修补程序来分发更新）。
答案 0 :(得分：0)
我不完全确定你的“特定”案例是什么。
如果您的“媒体播放器”适用于在您完全监督下一次更新所有媒体播放器或任何特定插件的众所周知的独特客户端（或一小组客户端），那么我将寻求静态库。
如果不是这样，我会选择动态库。优化很好，但不如客户/用户满意度好。没有什么比将xxx库更新到最新版本更糟糕了，所有突然的事情都停止工作。如果您无法控制更新的时间和方式，请尽可能灵活。
对评论的回复：
通常，动态库向后兼容次要版本，而静态链接可能依赖于具体版本，如果您尝试将其链接到另一个版本，则会中断。使用动态链接，只要您使用的调用没有改变，您的程序甚至可以工作，而静态链接可能取决于库中函数偏移的更改。
例如，静态库可能在运行时以静态偏移量加载到进程的地址空间中。当然，知道这个偏移量允许进行某些优化，但是如果你更新了库，那么要么使用该库更新所有插件，要么可能无法更新插件（因为函数偏移可能已经改变了）。
我假设您在运行时加载它们，虽然如果可以命名为静态链接在空中，在任何其他情况下，您将只在每个插件上拥有该库，并且将没有“共享”。