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