C++ 减少单个编译单元/Unity构建的缺点

我正在做一个大项目，这个项目将变得更大。在此之前，我想解决的一个问题是构建速度

在过去，我们使用单个编译单元/Unity构建来大大提高构建速度。详情可在此找到

实际上，您创建了一个.cpp文件，其中包含多个#include other.cpp

e、 g.scu.cpp的内容

#include apple.cpp
#include banana.cpp
#include cherry.cpp

namespace unique_1 {
#include apple.cpp
}
namespace unique_2 {
#include banana.cpp
}
namespace unique_3 {
#include cherry.cpp
}

这将创建一个scu.obj。这降低了构建速度，因为它减少了文件I/O

但也有不利之处

• .cpp中的全局变量/函数是共享的，可能会发生冲突
• 开发人员可能会忘记将文件包含在.cpp中，而不受影响

另一件坏事是，开发人员可能需要手动维护scu.cpp（但这对我们来说是自动化的，所以不需要担心）

由于这些缺点，我们离开了SCU。但是我很想把它带回来，因为构建速度的提高真的很诱人（减少50-75%）

有没有办法避免这些冲突？我测试了

scu.cpp的内容

#include apple.cpp
#include banana.cpp
#include cherry.cpp

namespace unique_1 {
#include apple.cpp
}
namespace unique_2 {
#include banana.cpp
}
namespace unique_3 {
#include cherry.cpp
}

但这只会产生错误

error C3083: 'vc_attributes': the symbol to the left of a '::' must be a type
........

源于#包含在名称空间中

还有别的选择吗？还有其他解决办法吗

此线程没有建议（很遗憾）

测试非SCU解决方案的单独构建是很容易实现的。但在我们的组织内，我们并不赞成。i、 e

全局变量/函数是有效的（在C++教科书中）
• 可能在未意识到的情况下破坏SCU/非SCU（直到发生构建破坏）

---

“全局变量…可能冲突”编译是一个整数问题，在具有良好文件系统缓存和大量RAM的现代计算机上，文件I/O对构建速度没有影响。通过将代码模块化为单独的可执行文件，您可以快速构建。对于大型项目，最好只重新构建代码发生更改的小组件。当所有内容都进入一个源文件时，一个小的更改意味着重新编译整个项目。我工作的一家公司使用了一个C#CLI应用程序，它可以读取源目录并输出兼容的项目文件和相关的unity文件。很好，但是有点粗糙；我更喜欢使用CMake，它还有其他好处，但我最喜欢的是它使用的脚本语言，它允许您自动创建unity源文件。试一试，你可能会惊讶于它的工作原理：us2012-我不是.cpp中globals的超级粉丝。看起来很像80年代。我认为应该把它们去掉。但它是有效的C++，很难论证当人们反对时。同意名称空间应该是一个有意识的选择。但我希望找到一些东西来减轻SCU的缺点。将整个代码库更改为使用名称空间对我来说并不实际。