e.exe 链接到我的自定义静态库 c.lib，它使用 w.dll 中定义的 Win32 API。 w.dll位于C:\Windows\System32，其导入库为w.lib，位于Windows SDK目录。 Shell w.lib 在 c.lib 或 e.exe 项目中被列为 Additional Dependency？ (e.exe 在这两种情况下都能成功构建。)最佳实践是什么？为什么？我想 e.exe 应该不知道 w.lib。
c.lib 仅供一组开发人员共享(不运送给客户)。
测试:我使用 VS2008 和 dumpbin 实用程序测试了这两种情况，结果如下:
- 案例 1:
w.lib添加为c.lib项目中的附加依赖项。
dumpbin/archivemembers c.lib 输出将 w.dll 和 c.lib 项目中的 .obj 文件中的偏移量列为存档成员.
- 情况 2:
w.lib未作为 附加依赖项 添加到c.lib中，而是添加到e.exe项目:
这一次，dumpbin 输出仅包含c.lib 的.obj 文件，并且c.lib 的大小比情况1 小
(在这两种情况下，c.lib 都作为 Additional Dependency 添加到 w.exe 项目中。)
注意:我在这里使用 w.lib 和 w.dll 作为 Windows 库的虚构通用名称，但它们可以是例如Userenv.lib 和 Userenv.dll 或 Version.lib 和 Version.dll...
最佳答案
我认为您误解了创建存档和导入存档的作用。
正如您在评论中正确推测的那样，创建存档会创建一个包含已编译 .objs 的统一文件。现在，这可以包含您喜欢的任何代码，包括但不限于对库的动态调用。导入库是一个包含专门进行此类调用的 obj 的库，其想法是通过导入它，您的 exe 可以找到适当的符号(它们必须在您创建的可执行文件中)。
从 w.lib 创建 c.lib 的过程只是提取 w.lib 的对象并将它们附加到集合中c.lib 中的对象。实际上，c.lib 变成了导入库 + 代码。
我认为你应该这样做吗？不是真的 - 它可能会导致混淆 e.exe 依赖什么；我认为你应该明确地让它可见而不是试图隐藏它。也就是说，这只是建议，不是规则。
关于c++ - 具有依赖关系的静态库，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4646937/