9

我见过不少项目（通常是游戏引擎），其中所有头文件都放在一个头文件中，有时还包含宏等，例如

// Master.h

#include "header1.h"
#include "header2.h"
#include "header3.h"
.
.
#include "headerN.h"

然后在使用代码时，标准是只包含 Master.h 文件。

其他项目的工作基础是源文件应该只包含他们需要的头文件。

我想知道的是，是否有关于最佳实践的明确答案，最好是可衡量的结果，还是个人偏好？

4

6 回答 6

7

大多数答案都提到了编译时间，而忽略了头文件的预编译具有巨大的编译时间优势这一事实，并且与主头文件技术一起工作得更好。

最好，如果在没有主头文件的情况下直接包含您的头文件（这使测试更容易），您的头文件应该可以工作。现代编译器已经优化了“如果多次包含则跳过头文件”逻辑。

于 2013-03-27T16:51:09.110 回答
2

从编译时间的角度来看，这绝对是一种不好的做法，因为每次修改文件或触及任何包含的标头时，都必须从头开始重新编译您的项目。

根据经验，您应该在源文件中包含尽可能少的标头。但是，我可以看到一些可能会派上用场的情况，第三方库不会经常更改

于 2013-03-27T16:47:49.987 回答
2

由于编译 C++ 很昂贵并且可能特别慢，我想说如果有很多头文件（或者有很多实现文件），您可以通过避免不必要地包含未使用的头文件来避免一些额外的预处理和解析时间这又包括标题）。

那是为了实现库（你提到游戏引擎让我觉得我们在这里谈论的是库）。现在，为了方便起见，您绝对可以制作一个“主”包含文件，以方便那些使用该库并希望将所有内容放在一个地方（并且不会同时拥有数千个文件）的人。

于 2013-03-27T16:47:57.717 回答
1

我还要补充一点，当库提供主文件时，只包含需要的标题是相当糟糕的主意。经常发生这样的标题不包含它需要的所有内容，而是取决于主标题将包含之前所有必需的标题的事实。所以，如果你是图书馆的用户，你通常没有太多选择，应该按照作者建议的方式。

这也是为什么拥有主标头可能被认为是不好的做法的原因——它使得更难检测到我上面描述的这种情况。

于 2013-03-27T17:18:44.510 回答
0

在我看来，由于没有输入正确的头文件的名称而获得的 5 秒肯定不值得由这种方法引起的编译时间的潜在巨大增加。

我会说这是不好的做法。

然而，正如 H2CO3 所说，为框架的最终用户提供使用主头文件的可能性会非常有帮助。如果我没记错的话，GTK 会这样做。

于 2013-03-27T16:48:38.943 回答
0

我认为 C++ 中的一些问题——还有这个问题——你可以通过记住 C++“口头禅”来回答自己

不要为你不使用的东西付费。

尽可能节省您的用户（即您的代码/库的消费者）计算成本（运行时和编译时）。不要污染命名空间并在编译器（也在语法荧光笔等处）抛出比需要更多的东西。我认为这是 C++ 的礼貌方式 :)

于 2013-03-27T18:26:13.033 回答