单一来源项目结构有哪些缺点？

我是目前公司的新人，正在从事由我的直接团队领导编写的项目。该公司通常不使用 C++，但我的同事用 C/C++ 编写了高效的代码。只有我们知道如何用 C++ 编码（我和我的领导，所以没有第三种意见可以涉及）。

在我对这个项目有了足够的了解之后，我意识到整个结构是......special.

它实际上由一个编译单元组成，其中 makefile 将其列为唯一源main.hpp.

然后，该头文件包含该项目组成的所有源文件，因此它看起来像是一个非常大的列表：

#include "foo.cpp"
#include "bar.cpp"

在尝试理解其背后的逻辑时，我意识到这确实适用于这个项目，因为它只是一个接口，每个单元都可以在不访问任何其他单元的情况下进行操作，在某些时候我问他这样做的原因是什么这边走。

我对争论产生了防御性反应

嗯，它正在发挥作用，不是吗？如果您认为这对您更好，您可以自由地按照自己的方式进行。

这就是我现在正在做的事情，仅仅是因为我在思考这个结构时确实遇到了困难。因此，现在我将“通常”结构应用于我现在正在编写的实现，同时仅对整个项目进行强制性更改，以演示我将如何设计它。

我认为存在很多缺点，从通过自己的项目结构混合链接器和编译器作业开始无法很好地服务，直到优化可能会导致冗余或模糊的结果，更不用说项目的干净构建需要大约30分钟，我认为也可能是结构造成的。但我缺乏知识来指出真实的问题，而不仅仅是假设的问题。

正如他的论点“这对我有用，不是吗？”确实如此，我希望能够向他解释为什么这是一个坏主意，而不是成为一个新的挑剔的人。

那么这样的项目结构实际上可能会导致哪些问题呢？ 或者我反应过度了，这样的结构完全没问题？

更不用说项目的（干净）构建大约需要 30 分钟

主要缺点是对代码任何部分的更改都需要从头开始重新编译整个程序。如果编译需要一分钟，这可能不会有什么意义，但如果需要 30 分钟，那就会很痛苦；它破坏了进行更改->编译->测试工作流程。

更不用说一个clean项目的构建大约需要 30 分钟

拥有单独的翻译单元实际上通常从头开始编译要慢一些，但您只需要在每个单元发生更改时单独重新编译它们，这是主要优点。当然，通过在所有翻译单元中包含大量且经常变化的标头，很容易错误地破坏这一优势。单独的翻译单元需要小心谨慎才能正确完成。

如今，使用多核 CPU，多个翻译单元允许的并行性可以缓解从头开始构建速度较慢的情况（如果单个翻译单元的大小碰巧达到最佳点，并且有足够的核心，那么这个缺点甚至可以被克服；您需要进行一些彻底的研究才能找到答案）。

另一个潜在的缺点是整个编译过程必须适合内存。仅当内存超过开发人员工作站上的可用内存时，这才会出现问题。

结论：问题在于单一大量源文件方法不能很好地扩展到大型项目。

现在，为了公平起见，谈谈优势

最多的优化可能会导致冗余或模糊的结果

实际上，单个翻译单元比单独的翻译单元更容易优化。这是因为某些优化（特别是内联扩展）无法跨翻译单元进行，因为它们依赖于当前编译的翻译单元中不存在的定义。

由于流行编译器的稳定版本中提供了链接时间优化，因此这种优化优势已被削弱。只要您能够并且愿意使用现代编译器，并启用链接时间优化（默认情况下可能不会启用）

附言。单曲的命名非常不合常规source带有扩展名的文件.hpp.