【问题标题】:Organizing static libraries for a C++ desktop app为 C++ 桌面应用程序组织静态库
【发布时间】:2020-04-02 10:06:33
【问题描述】:

我的 C++ 桌面应用程序是一个链接到十几个静态库(.lib 文件)并在静态库中使用 MFC 的 exe。 exe 的调试版本的总大小为 25 Mb。

我正在向其中添加一项新功能,我必须在创建新静态库或将我的功能添加到现有静态库之一之间做出选择。

有什么取舍?由于我们的静态库数量比较少,而且输出的 exe 也很少,那么简单地将我们所有的小库合并成一个大库有什么缺点?

【问题讨论】:

    标签: c++ architecture mfc static-libraries static-linking


    【解决方案1】:

    在回答您的问题之前,我认为重要的是要记住与libdll 的选择有关的问题。

    1. .lib的情况下

      • 无论库是否在运行时使用,二进制文件的大小都会随着库的大小而增加。
    2. .dll的情况下

      • .dll 会根据需要加载(在第一次调用期间),并且可以在程序的整个生命周期中在不同组件之间共享。

      • 它们具有更好的灵活性,因为它们可以以更加模块化的方式进行版本控制和管理

      • 您可以更好地管理兼容性问题,尤其是在更新期间。

    在你的情况下:

    • 通过选择基于.lib 的解决方案,您继承了.lib 的所有缺点...
    • 通过将不同的库组合成一个库,您会破坏解决方案的模块化:
      • 假设您将A.libB.lib 合并到C.lib 如果明天你只需要B.lib 功能,你将不得不链接C.lib,即使你只需要B.lib,你的二进制文件也会大大增加
    • 今天你的二进制文件很小,但你不知道明天会发生什么......

    只要事情不复杂,我认为有必要考虑这些方面来审查库的架构。
    代替你,我将选择基于 dll 的解决方案,通过促进我的库的调制。

    【讨论】:

    • 如果您链接到 DLL 的导入库(使用 .lib 文件),该 DLL 将在 load 时加载,而不是按需加载。除非您使用特殊的 /DELAYLOAD 链接器选项。你也错过了拨打Potential Errors Passing CRT Objects Across DLL Boundaries。这是相关的,并且对于 MFC 来说尤其麻烦。此外,MFC 在将代码放入 DLL 时有额外的要求。这个答案充其量是误导性的。
    • @IInspectable 此答案并非旨在提供有关 dll 的完整课程。只是为了提出新的想法
    • 无法回答的问题不应回答,而应关闭。无论如何,在回答标记为 mfc 的问题时忽略 MFC 的特殊性几乎是刑事疏忽。
    • 另外,“无论库是否在运行时使用,二进制文件的大小都会随着库的大小而增加” 是错误的。链接器链接单元(.obj 文件),一个库可能包含多个单元。仅当您实际使用它们包含的项目之一时,它们才会包含在可执行文件中,例如,如果您调用函数。即一个额外的库不会增加可执行文件的大小,除非你真的使用它。您可能希望将库的源代码拆分为多个源文件,以减少可执行文件(如果认为这很重要)。
    • 主啊,2 人赞成一个在技术上甚至不正确的答案。这个地方太失落了。让我重复一遍:默认情况下,DLL 不是“按需”加载,而是在进程加载时加载。
    猜你喜欢
    • 1970-01-01
    • 2012-10-08
    • 2012-04-18
    • 1970-01-01
    • 2010-11-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多