＃将所有.cpp文件包含到一个编译单元中？

Question

最近，我有理由使用一些Visual Studio C ++项目，这些项目具有通常的Debug和Release配置，但是还有“ Release All”和“ Debug All”，这是我以前从未见过的。事实证明，项目的作者只有一个ALL.cpp，其中#includes所有其他.cpp文件。*所有配置仅构建此一个ALL.cpp文件。它当然不包含在常规配置中，并且常规配置不会构建ALL.cpp我只是想知道这是否是常见的做法？它带来什么好处？（我的第一反应是闻起来很香。）您可能会遇到什么样的陷阱？我能想到的是，如果您的.cpps中有匿名名称空间，它们不再是该cpp的“专用”对象，而是现在也可以在其他cpps中看到？所有项目都构建DLL，因此将数据存储在匿名名称空间中不是一个好主意，对吗？但是功能会好吗？干杯。

Answer 1

Unity可以提高构建速度，主要有以下三个原因。第一个原因是所有共享头文件仅需要解析一次。许多C ++项目都有很多头文件，大多数或所有CPP文件都包含这些头文件，并且这些文件的冗余解析是编译的主要成本，尤其是在您有许多短源文件的情况下。预编译的头文件可以帮助您节省这笔费用，但通常会有很多未预编译的头文件。

统一构建会提高构建速度的下一个主要原因是，编译器的调用次数更少。调用编译器会产生一些启动成本。

最后，减少冗余标头解析意味着减少用于内联函数的冗余代码生成，因此目标文件的总大小较小，这使链接速度更快。

Unity构建也可以提供更好的代码生成。

由于磁盘I / O减少，Unity构建不会更快。我已经介绍了许多使用xperf的版本，我知道我在说什么。如果您有足够的内存，则OS磁盘缓存将避免冗余的I / O-头文件的后续读取将来自OS磁盘缓存。如果您没有足够的内存，那么统一编译甚至会导致编译器的内存占用量超过可用内存并分页，从而使编译时间更糟。

磁盘I / O昂贵，这就是为什么所有操作系统都积极缓存数据以避免冗余磁盘I / O的原因。

Answer 2

我想知道ALL.cpp是否试图将整个项目放在单个编译单元中，以提高编译器针对大小优化程序的能力？

通常，某些优化仅在不同的编译单元内执行，例如删除重复的代码和内联。

话虽如此，我似乎还记得最近的编译器（Microsoft，Intel的编译器，但我认为其中不包括GCC）可以跨多个编译单元进行此优化，因此我怀疑此“技巧”是不必要的。

就是说，很奇怪是否确实存在任何差异。