代码之家  ›  专栏  ›  技术社区  ›  Alex Jenter

减少cpp翻译单元的数量是一个好主意吗?

  •  13
  • Alex Jenter  · 技术社区  · 16 年前

    我发现,如果有很多类,当我为每个类使用一个*.h和一个*.cpp文件时,编译时间会显著增加。我已经使用了预编译头和增量链接,但编译时间仍然很长(是的,我使用boost;)

    所以我想出了以下窍门:

    • 将*.cpp文件定义为不可编译
    • 将*.cxx文件定义为可编译文件
    • 为每个应用程序添加了一个*.cxx文件 模块,并且#包含此模块的所有*.cpp文件。

    因此,我最终只得到了8个翻译单元,而不是100多个翻译单元。编译时间缩短了4-5倍。

    缺点是,您必须手动包含所有*.cpp文件(但这并不是一个维护噩梦,因为如果您忘记包含链接器会提醒您的内容),并且一些VS IDE便利设施不适用于此方案,例如转到/移动到实现等。

    所以问题是,拥有大量的cpp翻译单元真的是唯一正确的方法吗?我的把戏是已知的模式,还是我遗漏了什么? 谢谢

    8 回复  |  直到 16 年前
        1
  •  5
  •   BenMorel Manish Pradhan    11 年前

    这种方法的一个显著缺点是每个翻译单元有一个.obj文件。

    如果您创建一个静态库以便在其他项目中重用,那么如果您有多个大型转换单元而不是许多小型转换单元,那么在这些项目中您通常会遇到更大的二进制文件,因为链接器将只包含.obj文件,其中包含使用库的项目中真正引用的函数/变量。

    对于大的翻译单元,更有可能引用每个单元并包含相应的.obj文件。在某些情况下,较大的二进制文件可能是一个问题。也可能有些链接器足够聪明,只包含必要的函数/变量,而不包含整个.obj文件。

    此外,如果包含了.obj文件,并且也包含了所有全局变量,那么当程序启动/停止时,将调用它们的构造函数/析构函数,这肯定需要时间。

        2
  •  4
  •   Jim Buck    16 年前

        3
  •  3
  •   Timo Geusch    16 年前

    将大量C++源代码文件捆绑到单个文件中是最近几次提到的一种方法,尤其是当人们正在构建大型系统并拉入复杂的头文件(这将是一种提升)。

    正如您提到的VS一样,我发现项目中包含文件的数量,尤其是包含路径的大小,似乎对Visual C++的编译时间的影响远远大于对g++编译时间的影响。对于大量嵌套的include(boost也是这样做的),尤其如此,因为要查找源代码所需的所有include文件,需要进行大量的文件搜索。将代码合并到一个源文件中意味着编译器可以更智能地查找所述包含,而且可以找到的包含明显较少,因为您可以预期,同一子项目中的文件可能包含一组非常相似的头文件。

    对C++开发的“大量编译单元”通常来自于对类进行解耦并最小化类之间的依赖关系,因此编译器只需重建最小的文件集,以防发生任何更改。这通常是一种很好的方法,但通常在子项目中并不切实可行,因为其中的文件相互依赖,因此最终将进行相当大的重建。

        4
  •  3
  •   Konstantin Tenzin    16 年前

    1. 在开发过程中增加了编译时间。通常开发人员一次只修改几个文件,3-4个小文件的编译速度可能比一个非常大的文件更快。
    2. 正如您所提到的,更难导航代码,这一点非常重要。
    3. 在一个.cxx文件中包含的.cpp文件之间可能存在一些干扰:

      A.通常的做法是在cpp文件(用于调试构建)中本地定义新的宏以进行内存泄漏检查。不幸的是,在使用placement new(如某些STL和BOOST标头所做的那样)包含标头之前,无法完成此操作

      B在cpp文件中添加使用声明是常见的做法。在您的方法中,这可能会导致标题出现问题,包括后面的标题

        5
  •  2
  •   Robert S. Barnes Antoni    16 年前

    我不确定这是否与您的情况相关,但也许您可以使用声明而不是定义来减少 #include

        6
  •  1
  •   Cătălin Pitiș    16 年前

    较大和较小的翻译单元不会利用并行编译。我不知道您使用的是什么编译器和什么平台,但在并行多个翻译单元中编译可能会显著减少构建时间。。。

        7
  •  1
  •   Community CDub    8 年前

    这个概念叫做 unity build

        8
  •  0
  •   SmacL    16 年前