我进入了一个项目，该项目采用了使用包含每个.c文件的所有标头的头文件MyProject.h的方法。每个.c文件都有自己的头文件，其中包含#include "MyProject.h"，无论需要哪些库，以及该文件所需的任何其他声明。
对我来说，这似乎是多余的，有点不自然，但它编译并随后按预期运行。我的想法是编译器会做更多的工作而不是必要的，并且可能会使.exe过度膨胀。这样做的缺点是什么？
我接下来的一个问题是，我说使用上面的例子在一个文件中包含了一个像Time.h这样的库。由于MyProject.h，编译器是否只将Time.h构建到二进制文件或现在的每个文件中？结构，枚举等怎么样？？
答案 0 :(得分：5)
拥有这样的头文件是不好的做法和糟糕的设计。问题是，它会在项目的每个文件之间创建紧密耦合依赖关系，即使它们完全不相关。
良好的程序设计是创建仅包含其所使用资源的自主模块。他们应该从他们自己的h文件中做到这一点，以准确记录特定模块的依赖关系。
答案 1 :(得分：1)
主要缺点是增加了构建时间。每个源文件都包含项目的每个标题，无论是否需要它。
它在概念上也是不洁净的。源文件应包含所需的标头。应该可以搜索标题的名称以查找使用这些功能的源代码部分。最小化不必要的包含是松散耦合系统的证据。但是，包含 - 您使用的内容很难执行，因为您无法通过C中的标头阻止设施的可传输可用性。
不应导致可执行文件大小增加。即使头文件包含代码（在C中很少见，但在C ++中很常见），链接器也应该消除重复并删除未使用的代码。
答案 2 :(得分：0)
我的大多数库都有一个包含外部包含的预编译头，每个库包含一个“主”头，其中包含预编译的头文件+所有库的.h文件。我的所有.cpp文件首先包括预编译头，然后是主头。
就是这样。我的其他.h文件都没有包含任何内容。我的.cpp文件只包含这两个标题。其他需要使用该库的库将#include相同的主标题。
这样做大大简化了头文件头痛/复杂性问题，虽然我想补充一点，我的大多数库在宏观方案中相对较小。我不知道这是否适用于一个非常大的（怪物）项目。也许不是。
这种方式实际上非常好。上面的其他人，关注“耦合”想要最小化它，但如果你根本没有包含任何标题，你就会100％解耦，甚至是你的依赖关系。如果要重用该类，请使用包含它的库。
简单。
答案 3 :(得分：0)
之前的所有答案都很清楚，但是。
“一个大头文件”的主要缺点是代码可重用性的问题。例如，您已经创建了一些模块作为应用程序的一部分。假设这个模块为某些硬件实现了API。然后你想制作另一个应该使用这个模块的应用程序。
在这种情况下，您必须记住编译此模块时必须包含哪些头文件，或者，如果您只是复制以前的“大头文件”，则需要大量不必要的第三方库和头文件。 / p>
没有人愿意花费大量时间来制作一些模块。如果你能开箱即用它会好得多，不是吗？