c++ - 单一来源项目结构的缺点是什么？

Question

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

在我对项目有了足够的了解后，我意识到整个结构是......特别。

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

然后这个头文件包含项目所包含的所有源文件，所以它看起来像一个非常大的列表:

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

在试图理解其背后的逻辑时，我意识到这确实适用于这个项目，因为它只是一个接口(interface)，每个单元都可以在其中运行而无需访问任何其他单元，在某个时候我问他为什么他是这样做的。

我对这个论点产生了防御 react

Well, it is working, isn't it? You are free to do it your way if you think that's better for you.

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

我认为有很多缺点，首先是通过自己的项目结构混合链接器和编译器工作不能很好地服务，直到可能以冗余或模糊结果结束的优化，更不用说干净的构建该项目需要大约 30 分钟，我认为这也可能是由结构引起的。但是我缺乏知识来命名真实的而不仅仅是假设的问题。

正如他的论点“它按我的方式行事，不是吗？”成立，我希望能够向他解释为什么这是一个坏主意，而不是像新挑剔的人一样过来。

那么这样的项目结构实际上会导致什么问题呢？ 还是我 react 过度了，这样的结构完全没问题？

Answer 1

not to mention that a (clean) build of the project takes ~30 minutes

主要缺点是对代码的任何部分进行更改都需要从头开始重新编译整个程序。如果编译需要一分钟，这可能并不重要，但如果需要 30 分钟，那将是痛苦的；它破坏了 make a change->compile->test 工作流程。

not to mention that a clean build of the project takes ~30 minutes

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

现在，使用多核 CPU，从头开始构建的速度会因多个翻译单元允许的并行性而得到缓解(如果单个翻译单元的大小恰好达到最佳点，这个缺点甚至可能会被克服，并且有足够的内核；您需要进行一些彻底的研究才能找到答案)。

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

总而言之:问题在于单一海量源文件方法不能很好地扩展到大型项目。

---

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

up to optimizations will probably end in redundant or obscure results

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

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

---

附言。将单个源 文件命名为扩展名为.hpp 是非常不合常规的。