I'm not completely sure of what your "specific" case is.
If your "media player" is intended for a well know unique client (or small set of clients) who will update all the media player at once or any given plugin at once under your complete supervision then I'll go for static libraries.
If that's not the case I'll go for dynamic libraries. Optimizations are good but are not as good as customer/user satisfaction. There's nothing worse than updating your xxx library to the latest version and that all the sudden things just stop to work. If you haven't control over when and how updates are made be as flexible as you can.
Response to the comment:
Usually dynamic libraries are backwards compatible for minor release versions while static linking might be dependent on a concrete version and break if you try to link it to another release. With Dynamic Linking your program might even work as long as the calls you use doesn't change while static linking might depend on a change of the function offset in the library.
For example, static libraries might be loaded in runtime into the address space of the process at an static offset. Of course, knowing this offset allows for certain optimizations but if you update the library then either you update ALL the plugins using that library or probably the unupdated plugins won't work (as function offset might very well have changed).
I assume you load them in runtime, although if that can be named static linking is in the air, in any other case you will just have the library on each plugin and there will be no "sharing".
发布评论
评论（1）
我不完全确定你的“具体”案例是什么。
如果您的“媒体播放器”是针对一个众所周知的独特客户端（或一小部分客户端），他们将在您的完全监督下立即更新所有媒体播放器或立即更新任何给定的插件，那么我将选择静态库。
如果不是这种情况，我会选择动态库。优化固然不错，但不如客户/用户满意度。没有什么比将你的 xxx 库更新到最新版本更糟糕的了，然后所有的事情突然停止工作。如果您无法控制更新的时间和方式，请尽可能灵活。
对评论的回应：
通常动态库向后兼容次要版本，而静态链接可能依赖于具体版本，如果您尝试将其链接到另一个版本，则会中断。使用动态链接，只要您使用的调用不改变，您的程序就可以工作，而静态链接可能取决于库中函数偏移量的变化。
例如，静态库可能在运行时以静态偏移量加载到进程的地址空间中。当然，知道这个偏移量可以进行某些优化，但是如果您更新库，那么要么您更新使用该库的所有插件，要么未更新的插件可能无法工作（因为函数偏移量很可能已经改变）。
我假设您在运行时加载它们，尽管如果可以将其命名为静态链接，则在任何其他情况下您将只在每个插件上拥有库并且不会有“共享”。
I'm not completely sure of what your "specific" case is.
If your "media player" is intended for a well know unique client (or small set of clients) who will update all the media player at once or any given plugin at once under your complete supervision then I'll go for static libraries.
If that's not the case I'll go for dynamic libraries. Optimizations are good but are not as good as customer/user satisfaction. There's nothing worse than updating your xxx library to the latest version and that all the sudden things just stop to work. If you haven't control over when and how updates are made be as flexible as you can.
Response to the comment:
Usually dynamic libraries are backwards compatible for minor release versions while static linking might be dependent on a concrete version and break if you try to link it to another release. With Dynamic Linking your program might even work as long as the calls you use doesn't change while static linking might depend on a change of the function offset in the library.
For example, static libraries might be loaded in runtime into the address space of the process at an static offset. Of course, knowing this offset allows for certain optimizations but if you update the library then either you update ALL the plugins using that library or probably the unupdated plugins won't work (as function offset might very well have changed).
I assume you load them in runtime, although if that can be named static linking is in the air, in any other case you will just have the library on each plugin and there will be no "sharing".