所以这听起来有点疯狂，但我有以下想法...
在c ++中，当您使用#include将所有代码放在一个文件中或简单地复制和粘贴时，它们会调用统一构建。这允许快速编译。
现在为了简单起见假设我们只有一个头文件库，我们仅限于使用类（这样我们就有了一个garaunteed命名空间）。 现在，我想知道如果自动化，这将有多好。将使用脚本/工具预处理.h文件;挑选包含和依赖。该工具将递归地遍历每个.h文件并构造包含依赖关系的映射。然后，它将使用#includes和compile。将这些依赖项放在一个文件（main.cpp）中。
现在我希望得到你的家伙对自动统一构建创造者这个想法的看法。这样聪明吗？它会像我期望的那样起作用吗？
答案 0 :(得分：1)
Unity构建过分，真的。
这允许快速编译。
这些日子并不完全正确。假设您有专用的机器用于具有足够RAM的编译，则编译不受I / O限制。每个现代操作系统在首次读取后缓存文件，而不是从内存中获取文件。您可以通过管道或将它们存储在RAM驱动器中来避免中间文件。因此预处理器工作只是在大多数时间连接文件。这很快。实时用于编译和链接。
因此任何拥有数千个文件的严肃应用都将是巨大的。真实世界的例子 - 我们使用app，其中源代码需要超过100MB的数据（没有系统和第三方包括）。因此，您的系统必须以大约150MB的文件运行。如果一些编译器拒绝编译它，我不会感到惊讶。更不用说编译时间了。最好分成较小的文件并并行编译。再一个真实的例子 - 单线程编译需要40分钟才能完成，在一台服务器上运行16个线程大约需要2.5-3分钟，并在16个服务器的服务器上进行编译，每个16个核心，使用distcc 30秒加上一些时间进行链接。
团结构建的另一个好处是，当完成LTO和静态构建时，更好的优化会消失。
回答你的问题 - 是的，你可以做到这一点。是否有意义？疑。
答案 1 :(得分：0)
你做了什么？
你讨厌“只有头”，因为你“每次都需要重新编译世界”。在你的“勇敢的新世界”中，只有一个文件，所以每次都会编译 - 无论如何。
人们花费了大量的时间和精力来制作C ++，以便它可以使用库等来帮助加快编译速度。哦，顺便说一句，我今天看到的系统有1700多万行代码。你想要在一个文件中吗？
OP在评论中提供的链接是一个很好的解释。我看到的一个大问题是可扩展性。它确实让我想起了我的（继承）代码库中的一个区域，其中守卫在包含之外以避免打开文件。 e.g。
#ifndef BLAH_H
#include <blah.h>
#endif