单源项目结构的缺点是什么?

What are the drawbacks of single source project structures?

本文关键字：是什么 缺点 项目 结构 单源      更新时间：2023-10-16

我是当前公司的新手，并从事我直接团队负责人撰写的项目。该公司通常不与C 合作，但是我的同事在C/C 上写了生产代码。只是我们知道如何在C 中进行编码（我和我的领导者，所以没有第三意见可以涉及）。

我对项目有足够的见解后，我意识到整个结构是... special 。

它实际上由单个汇编单元组成，其中makefile列表仅为 main.hpp。

此headerFile随后包含该项目组成的所有源文件，因此看起来确实很大：

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

试图理解其背后的逻辑，我意识到这确实为该项目起作用，因为它只是一个接口，每个单元可以在不访问任何其他单元的情况下运行，但在某个时候，我问他是什么原因他这样做了。

我对参数有防御性反应

好吧，它在起作用，不是吗？如果您认为这对您更好。

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

我认为有很多缺点，首先要通过自己的项目结构进行混合和编译器作业的工作，无法良好地服务，以至于优化可能会以多余的或晦涩的结果结束，更不用说清洁的建筑该项目需要约30分钟，我认为这也可能是由结构引起的。但是我缺乏命名真实的知识，而不仅仅是假设的问题。

和他的论点"它有效，不是吗？"诚然，我想能够向他解释为什么这是一个坏主意，而不是作为新的Nit Picky Guy。

那么，这种项目结构实际上可能引起什么问题？还是我反应过度，这样的结构完全很好？

更不用说项目的（干净）需要〜30分钟

主要缺点是，对代码的任何部分的更改都需要从划痕重新编译整个程序。如果汇编需要一分钟，这可能并不重要，但是如果需要30分钟，那将是痛苦的。它破坏了更改 -> compile->测试工作流程。

更不用说清洁构建项目需要〜30分钟

具有单独的翻译单元通常要慢得多，可以从头开始编译，但是您只需要在更改时分别重新编译每个单元，这是主要优势。当然，很容易通过在所有翻译单元中包含一个巨大的，经常更改的标头来错误地破坏这一优势。单独的翻译单元需要一点谨慎。

如今足够的核心；您需要进行一些详尽的研究才能找出）。

另一个潜在的缺点是整个汇编过程必须适合内存。这只是一个问题，当该内存变得比开发人员工作站上的免费内存更多时。

总结：问题是一个象征福文件的方法不能很好地扩展到大型项目。

现在，关于优势的一句话，公平性

进行优化可能会以多余或晦涩的结果结束

实际上，单个翻译单元比单独的翻译单元更容易优化。这是因为在翻译单元中不可能进行一些优化，特别是在线扩展，因为它们取决于当前编译的翻译单元中不存在的定义。

由于链接时间优化已在流行的编译器的稳定版本中获得，因此这种优化优势已经得到了减轻。只要您有能力并且愿意使用现代编译器，并启用链接时间优化（默认情况下可能不会启用）

ps。用扩展名.hpp。

我想提到的第一件事是单个编译单元的项目的优点：

  • 急剧汇编时间缩短。这实际上是切换到SCU的主要原因之一。当您有一个常规项目时，带有n翻译单元的汇编时间将在每个新的翻译单元中线性增长。虽然使用SCU，它将增长〜对数，并在大型项目中添加新单元几乎不会影响汇编时间。
  • 汇编内存减少。光盘和公羊。"大"翻译单元显然将比每个人"小"要占有更多的记忆。翻译单元仅包含项目的一部分，但是它们的累积尺寸将大大超过" Big"的大小。翻译单元。
  • 一些优化好处。显然，您会得到"一切都是内联的"。自动。
  • 不再担心"从头开始汇编"。这很重要，因为它是CI服务器执行的。

现在不利：

  • 开发人员必须保持严格的标题组织纪律。标题警卫，#include指令的一致排序，强制包括当前文件直接要求的标头，正确的转发，一致的命名约定等。问题在于，没有工具可以帮助开发人员进行此类措施，甚至在Header组织中违规，甚至可能导致较小的违规行为凌乱失败的构建日志。
  • 项目中文件总量的潜在增加。有关详细信息，请参见此答案。
  • "不再是编译"木剑围栏的借口。

P.S。

  • 在您的情况下，SCU组织是"煮"的一种。我的意思是，项目仍然具有不合适的标题的翻译单元。通常，当旧项目转换为SCU时，就会发生这种情况。
  • 如果使用SCU构建您的项目需要约30分钟，我觉得这不是项目组织的错（可能是防病毒，无SSD，递归模板膨胀），或者如果没有SCU，则需要几个小时。/li>
  • 一些数字：汇编时间从〜14分钟下降到〜20秒，可执行尺寸减小（从我的经验中将现有项目转换为SCU的结果）
  • 现实世界中用例：CPPCON 2014：巨大AAA游戏中的c '＆quot＆quot＆quot＆quort＆quarmium jumbo/unity builds builds builds'可以节省全部构建的时间＆quot＆quot＆quot" ））
  • 我可能有点夸张，但在我看来，"多个翻译单元"的整个概念'（以及静态库）过去应该留在过去。
相关文章：