最近，我有理由要使用常规的Debug和Release配置来处理某些Visual Studio C ++项目，还需要处理“ Release All”和“ Debug All”，这是我以前从未见过的。
事实证明，项目的作者只有一个ALL.cpp，其中#includes所有其他.cpp文件。*所有配置仅构建此一个ALL.cpp文件。它当然不包含在常规配置中，并且常规配置不会构建ALL.cpp
我只是想知道这是否是常见的做法？它带来什么好处？（我的第一反应是闻起来很香。）
您可能会遇到什么样的陷阱？我能想到的是，如果您的.cpps中有匿名名称空间，它们不再是该cpp的“专用”对象，而是现在在其他cpps中也可见？
所有项目都构建DLL，因此将数据存储在匿名名称空间中不是一个好主意，对吗？但是功能会好吗？
Answers:
一些人（并且可以在Google上使用）将其称为“ Unity Build”。它疯狂地快速链接，并且编译也很快。它非常适合不需要迭代的构建，例如从中央服务器发布的构建，但是不一定适合增量构建。
这是要维护的PITA。
编辑：这是第一个google链接，以获取更多信息：http : //buffered.io/posts/the-magic-of-unity-builds/
快速实现的事情是，编译器只需要读入所有内容一次，然后进行编译，然后进行链接，而不是对每个.cpp文件执行此操作。
布鲁斯·道森（Bruce Dawson）在他的博客上对此写得更好：http : //randomascii.wordpress.com/2014/03/22/make-vc-compiles-fast-through-parallel-compilation/
Unity可以提高构建速度，主要有以下三个原因。第一个原因是，所有共享头文件只需要解析一次。许多C ++项目都有很多头文件，大多数或所有CPP文件都包含这些头文件，而这些文件的冗余解析是编译的主要成本，尤其是当您有许多短源文件时。预编译的头文件可以帮助您节省这笔费用，但是通常会有很多未预编译的头文件。
统一构建会提高构建速度的下一个主要原因是，编译器的调用次数更少。调用编译器会产生一些启动成本。
最后，减少冗余标头解析意味着减少内联函数的冗余代码生成，因此目标文件的总大小较小，这使链接速度更快。
Unity构建也可以提供更好的代码生成。
由于磁盘I / O减少，Unity构建不会更快。我已经介绍了许多使用xperf的版本，我知道我在说什么。如果您有足够的内存，则OS磁盘高速缓存将避免冗余I / O-头文件的后续读取将来自OS磁盘高速缓存。如果您没有足够的内存，那么统一编译甚至会通过导致编译器的内存占用超过可用内存并分页来使编译时间更糟。
磁盘I / O昂贵，这就是为什么所有操作系统都积极缓存数据以避免冗余磁盘I / O的原因。
我想知道ALL.cpp是否试图将整个项目放在单个编译单元中，以提高编译器针对大小优化程序的能力？
通常，某些优化仅在不同的编译单元内执行，例如删除重复的代码和内联。
话虽如此，我似乎还记得最近的编译器（Microsoft，Intel的编译器，但我不认为其中包括GCC）可以跨多个编译单元进行此优化，因此我怀疑此“技巧”是不必要的。
就是说，很奇怪是否确实存在任何差异。
我同意布鲁斯的观点。根据我的经验，我曾尝试为我的.dll项目之一实施Unity Build，该项目具有大量的头文件包含和许多.cpps；为了减少VS2010上的总体编译时间（已经用尽了“增量生成”选项），但我没有减少编译时间，而是用光了内存，并且该生成甚至无法完成编译。
但是要添加；我确实发现在Visual Studio中启用“多处理器编译”选项非常有助于减少编译时间。我不确定其他平台编译器是否提供这样的选项。
除了Bruce Dawson的出色答案之外，以下链接还为统一构建的利弊提供了更多见解-https: //github.com/onqtam/ucm#unity-builds