单一源项目结构的缺点是什么? [英] What are the drawbacks of single source project structures?

问题描述

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

I'm new in my current company and working on a project written by my direct team lead. The company usually doesn't work with C++ but there is productive code written by my coworker in C/C++. It's just us who know how to code in C++ (me and my lead, so no 3rd opinion that can be involved).

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

After I got enough insight of the project I realized the whole structure is... special.

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

It actually consist of a single compilation unit where the makefile lists as only source the main.hpp.

然后，此头文件包括项目组成的所有源文件，因此看起来像是其中的一个很大的列表:

This headerfile then includes all the source files the project consists off, so it looks like a really big list of this:

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

在试图理解其背后的逻辑时，我意识到这确实适用于该项目，因为它只是每个单元可以在不访问任何其他单元的情况下进行操作的界面，有时我问他为什么他是这样做的.

While trying to understand the logic behind it and I realized that this is indeed working for this project, as it's just an interface where each unit can operate without accessing any other unit, at some point I asked him what are the reasons why he did it this way.

我对论点有反感

嗯，它在起作用，不是吗?如果您认为这对自己更好，则可以自由地这样做.

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

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

And that's what I'm doing now, simply because I'm really having trouble with thinking into this structure. So for now I'm applying the "usual" structure to the implementation I'm writing right now, while doing only mandatory changes to the whole project, to demonstrate how I would have designed it.

我认为有很多缺点，从混合链接器和编译器开始，按自己的项目结构无法很好地完成工作，而优化可能最终会导致冗余或模糊的结果，更不用说干净的构建了.该项目大约需要30分钟的时间，我认为这也可能是结构造成的.但是我缺乏命名真实性的知识，而不仅是假设性的问题.

I think there are a lot of drawbacks, starting with mixing linkers and compilers jobs by own project structure can't serve well, up to optimizations that will probably end in redundant or obscure results, not to mention that a clean build of the project takes ~30 minutes, what I think might be caused by the structure as well. But I'm lacking the knowledge to name real and not just hypothetical issues with this.

正如他的论点以我的方式运作，不是吗?"没错，我想能够向他解释为什么这还是个坏主意，而不是成为新的挑剔的家伙.

And as his argument "It works my way, doesn't it?" holds true, I would like to be able to explain to him why it's a bad idea anyway, rather than coming over as the new nit picky guy.

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

So what problems could actually be caused by such a project structure? Or am I overreacting and such a structure is totally fine?

推荐答案

更不用说，(干净的)项目构建需要大约30分钟的时间

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

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

The main drawback is that a change to any part of the code will require the entire program to be recompiled from the scratch. If the compilation takes a minute, this would probably not be significant, but if it takes 30 min, it's going to be painful; it destroys the make a change->compile->test workflow.

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

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

拥有单独的翻译单元通常从头开始编译要慢很多，但是您只需在更改每个单元时分别重新编译，这是主要优点.当然，很容易通过在所有翻译单元中包含庞大且经常更改的标头来错误地破坏此优势.单独的翻译部门需要注意一些正确的事情.

Having separate translation units is actually typically a quite a bit slower to compile from scratch, but you only need to recompile each unit separately when they're changed, which is the main advantage. Of course, it is easy to mistakenly destroy this advantage by including a massive, often changing header in all translation units. Separate translation units take a bit of care to do it right.

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

These days, with multi core CPU's, the slower build from scratch is mitigated by parallelism that multiple translation units allow (perhaps the disadvantage may even be overcome if the size of individual translation units happen to hit a sweet spot, and there are enough cores; you'll need some thorough research to find out).

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

Another potential drawback is that the entire compilation process must fit in memory. This is only a problem when that memory becomes more than the free memory on your developers workstations.

结论:问题在于，一个庞大的源文件方法无法很好地适用于大型项目.

In conclusion: The problem is that one-massive-source-file approach does not scale well to big projects.

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

Now, a word about advantages, for fairness

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

up to optimizations will probably end in redundant or obscure results

实际上，单个翻译单元比单独的翻译单元更易于优化.这是因为跨翻译单元无法进行某些优化，尤其是行内扩展，因为它们取决于当前编译的翻译单元中没有的定义.

Actually, the single translation unit is easier to optimize than separate ones. This is because some optimizations, inline expansion in particular, are not possible across translation units because they depend on the definitions that are not in the currently compiled translation unit.

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

This optimization advantage has been mitigated since link time optimization has been available in stable releases of popular compilers. As long as you're able and willing to use a modern compiler, and to enable link time optimization (which might not be enabled by default)

PS.用扩展名.hpp命名单个 source 文件是非常不常规的.

PS. It's very un-conventional to name the single source file with extension .hpp.

这篇关于单一源项目结构的缺点是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！