C++ 在我的代码中大量包含.h文件

我做了几年程序员

我总是被告知（并告诉其他人）你应该在你的.c文件中只包含你需要的.h文件。不多不少

但让我问一下——为什么

使用今天的编译器，我可以包含项目的整个h文件，并且不会对编译时间产生太大影响

我不是说包括OS.h文件，它包括许多定义、宏和预处理命令

只包括一个“MyProjectIncludes.h”。这只能说明：

#pragma once
#include "module1.h"
#include "module2.h"
// and so on for all of the modules in the project

---

你怎么说？

它会影响你的构建时间。此外，您还可能会有一个

的风险。通常，您不希望重新编译模块，除非它们实际依赖的头被更改。对于较小的项目，这可能无关紧要，全局“include_everything.h”文件可能会使项目变得简单。但在大型项目中，编译时间可能非常重要，最好尽量减少模块间的依赖关系。最小化不必要的头的包含只是一种方法。使用仅由指针或引用引用的类型的前向声明，使用Pimpl模式、接口和工厂等，都是旨在减少模块之间依赖性的方法。这些步骤不仅可以减少编译时间，而且可以使系统更易于测试和修改

---

关于这个主题，一个优秀的、虽然有些过时的参考，是肯定的，正如您所说的，包括额外的文件不会对您的编译时间造成太大的伤害。正如您所建议的，使用1 include行转储所有内容更方便

---

但是，如果一个陌生人确切地知道您在一个特定的

.c

文件中使用了什么

.h

文件，您不觉得他们可以更好地理解您的代码吗？对于初学者来说，如果您的代码有任何bug，并且这些bug在

.h

文件中，他们就会确切地知道要检查哪些

.h

文件

这与.c文件的编译时间过长无关，因为它包含了太多的头文件。正如您所说的，包含一些额外的头文件可能不会对该文件的编译时间产生太大影响

真正的问题是，一旦您使所有.c文件都包含“主”头文件，那么每次更改任何.h文件时，都需要重新编译每个.c文件，因为您使每个.c文件都依赖于每个.h文件。因此，即使你做了一些无害的事情，比如添加一个新的

#define

，只使用一个文件，你也会强制重新编译整个项目。如果您与团队一起工作，并且每个人都频繁地更改头文件，则情况会变得更糟

---

如果重建整个项目的时间很短，比如不到1分钟，那么就没那么重要了。我承认，为了方便起见，我在小项目中做了你建议的事情。但是，一旦您开始处理一个需要几分钟才能重建所有文件的大型项目，您就会明白需要重建一个文件与重建所有文件之间的区别

“我可以包含项目的整个h文件，它不会对编译时间产生太大影响。”这样，您就不会在很大的代码库中工作。不仅要考虑编译时间，还要考虑构建时间。构建过程确定了需要编译的模块和不需要编译的模块之间的关系。因此，编译一个未更改且不依赖已更改文件的模块是浪费时间和资源的。这就是预编译头背后的理论——编译一次大标题球，然后将结果读入每个源文件而不重新编译。即使构建时间不受影响，让每个模块详细说明其依赖关系有一个可读性优势，但事实并非如此。因为每个h文件包含更多的文件，它还包含其他几个文件。我发现自己正在维护要包含在每个文件中的.h文件列表。。。挺烦人的