将所有包含放在一个头文件中是一个好主意吗？

C放入C头文件的最佳做法是什么？

将所有用于程序的包含放在一个头文件中的多个源文件中是否有用？

几乎每个文件（即stdio.h）中使用的包含怎么样？

Answer 1

不，它只是增加了残余和开销。

作为维护者，您将面临的最大痛苦之一就是找出不需要包含哪些标题并将其删除。 当你到达20多个标题的列表时，你开始考虑丑陋的事情，比如暴力强迫它（一次删除一个并查看是否有任何中断）。

善待未来必须维护你的东西的人。 使用每个模块所需的标题，不多……不少:)

Answer 2

我个人订阅了“把它放在你使用它的地方”的理念。 它使得哪些文件使用什么，依赖关系等等更清晰。

想象一下，你有一个标题MyHeader.h 。 如果你在需要更改依赖它的代码进行更改，那么很容易找到依赖代码，如果使用它的每个文件都有#include "MyHeader.h" – 你可以只对include语句进行全局搜索。

另一方面，如果只将MyHeader.h包含在其他标题MyHugeHeader.h ，然后在文件中包含它 ，则不能这样做，因为使用MyHeader.h的文件中的所有MyHeader.h都是#include "MyHugeHeader.h" ，和其他文件一样。

Answer 3

将所有可能的标头放在一个应用程序标头中就像错误一样错误。

这是懒惰，价格很高。 它使构建变得脆弱。 这使得很难理解真正的依赖关系在哪里，因此难以重构或以其他方式重用代码。

这使得很难测试。

但最大的问题是，它代表了智力上的懒惰，并鼓励更多相同的东西。

与所有编程问题一样，做所需要的，不多也不少。 考虑维护。 考虑构建管理。

想一想。

Answer 4

有些事情尚未指出：

• 不需要的依赖项增加了编译时间。 修改标题时，您必须重新编译直接或间接包含它的所有编译单元。 如果不需要包含，则重新编译也不是。 你的程序越大，问题就越大，特别是如果你把你的程序分解成了必须手动触发重新编译的组合。

• 添加不需要的依赖项时，预编译器头可能更有效。

Answer 5

个人偏好真的……只要你保持一致（这使得它易于阅读），它的格式无关紧要。 你可以把它全部放在1个头文件中，或者你可以把它放在需要它的每个文件中。 它还取决于其他包含是如何加载主要不需要其包含之后的任何内容等所以使用相同的头文件为所有其他C文件可能或不可能（取决于编译器）包括相同的包含多个倍。

编辑：我也同意Mac，把它放在你使用它的地方也是一件非常非常好的事情

Answer 6

我不会故意将所有包含放入单个头文件中，只是因为如果更改其中一个包含的头文件，则必须重新编译包含“master”包含文件的所有内容。 这可能导致单个线路更改的编译时间不必要地长。

也就是说，我不会花太多时间来确保我对包含语句不太自由。 一些工程师将花费大量时间来减少包含以节省编译时间，并且我认为他们的时间可以更好地解决问题或处理新function。

Answer 7

头文件实际上是您从c程序中包含的内容。 它包含结构，宏，函数定义等数据结构。有时单个头文件可以正常，如果你的程序成长为逻辑组件，那么你可能需要更多。