在单个编译单元中包含所有 .cpp 文件的潜在好处和陷阱
在某些 Visual Studio C 项目中，出现了一种特殊的方法：合并单个 ALL .cpp 以包含所有其他 .cpp 文件。这种技术导致指定的“释放全部”和“调试全部”配置，引发了对其实用性的质疑。
好处：
-
Swift编译：编译器只执行一次耗时的读入和编译过程，减少构建
-
快速链接：单一编译单元简化了链接，进一步加速了构建过程。
陷阱：
-
困难维护：管理单个庞大的代码文件可能会变得笨重，可能会妨碍代码的可读性和灵活性。
-
匿名命名空间可访问性：将所有 .cpp 文件包含在一个单元中可以消除它们在各自的文件中进行有意的隔离，允许跨所有其他 .cpps 访问其内容。
-
命名空间冲突：如果不同的 .cpp 文件使用相同的命名空间，则会出现潜在的冲突，需要仔细注意命名空间的使用。
-
降低增量可构建性：需要对单个 .cpp 文件进行更改重新编译整个 ALL.cpp，减慢增量开发周期。
虽然 unity虽然它们在大规模、稳定的构建中表现出色，但它们的缺点可能会限制它们在代码更改频繁的增量开发环境中的有用性。必须权衡利弊，以确定这种方法是否最适合特定项目。
其他见解：
- Bruce Dawson 提供了一种-他的博客上对此主题进行了深入分析： http://randomascii.wordpress.com/2014/03/22/make-vc-compiles-fast-through-parallel-compilation/
- 有关更多信息，请参阅：http://buffered.io/帖子/unity-builds 的魔力/
以上是对于 C 项目来说，将所有 .cpp 文件合并到一个编译单元中是明智的方法吗？的详细内容。更多信息请关注PHP中文网其他相关文章！
