依靠标头包含传递性是一种好习惯吗？

我正在清理正在处理的C ++项目中的包含，并且我一直在想是否应该将直接使用的所有标头明确包含在特定文件中，还是应该仅包含最低要求。

这是一个例子Entity.hpp：

#include "RenderObject.hpp"
#include "Texture.hpp"

struct Entity {
    Texture texture;
    RenderObject render();
}

（让我们假设对它的前向声明RenderObject不是一种选择。）

现在，我知道其中RenderObject.hpp包括Texture.hpp-我知道，因为每个人RenderObject都有一个Texture成员。不过，我还是明确地将Texture.hppin 包含在内Entity.hpp，因为我不确定依赖于in是一个好主意RenderObject.hpp。

因此：这是一种好的做法吗？

无论您对这些文件中的内容有什么了解，都应始终包括所有标头，该标头定义该文件中.cpp文件中使用的任何对象。您应该在所有头文件中包含保护措施，以确保多次包含头都没有关系。

原因：

• 对于清楚阅读源代码的开发人员来说，这很清楚，这是有关源文件的要求。在这里，查看文件前几行的人可以看到您正在处理Texture此文件中的对象。
• 这避免了当重构的标头本身不再需要特定的标头本身时导致编译问题的问题。例如，假设您意识到RenderObject.hpp实际上并不需要Texture.hpp它。

必然的结果是，除非该文件中明确需要，否则不要在另一个标头中包含标头。

一般的经验法则是：包括您使用的内容。如果直接使用对象，则直接包含其头文件。如果您使用的对象A使用B，但您自己却不使用B，则仅包含Ah

同样，当我们在主题上时，仅应在头文件中实际需要时才在头文件中包括其他头文件。如果仅在.cpp中需要它，则仅在其中添加它：这是公共和私有依赖项之间的区别，并且将防止您的类用户拖入他们真正不需要的标头。

我一直在想我是否应该明确包括直接在特定文件中使用的所有标头

是。

您永远都不知道其他标头何时会更改。在每个翻译单元中都包含您知道翻译单元需要的标头，这在世界范围内都是有意义的。

我们有标题保护措施，以确保双重包含不会有害。

对此有不同的意见，但我认为每个文件（无论是c / cpp源文件还是h / hpp头文件）都应该能够自行编译或分析。

因此，所有文件都应#include他们需要的所有头文件-您不应该假定以前已包含一个头文件。

如果您需要添加头文件并发现它使用的是在其他地方定义的项目而没有直接包含它，那真是一件痛苦的事，因此您必须去查找（并且可能会得到错误的文件！）

另一方面，＃include一个不需要的文件（通常）并不重要...

作为个人风格，我按字母顺序排列#include文件，分为系统和应用程序-这有助于加强“自包含且完全一致”的信息。

它取决于传递包含是否是必需的（例如，基类）还是由于实现细节（私有成员）而定。

为了明确起见，仅在首先更改中间标头中声明的接口之后，才可以在删除传递包含时将其包括在内。由于这已经是一个重大更改，因此无论如何都必须检查使用该文件的任何.cpp文件。

示例：Bh包含Ah，C.cpp使用。如果Bh在某些实现细节上使用了Ah，则C.cpp不应假定Bh将继续这样做。但是，如果Bh对基类使用Ah，则C.cpp可以假定Bh将继续为其基类包括相关的标头。

您将在此处看到不复制标头包含项的实际优势。假设Bh使用的基类确实不属于Ah，而是重构为Bh本身。Bh现在是独立的标头。如果C.cpp多余地包含Ah，则它现在包含不必要的头。

可能还有另一种情况：您有Ah，Bh和您的C.cpp，Bh包括Ah

所以在C.​​cpp中，您可以编写

#include "B.h"
#include "A.h" // < this can be optional as B.h already has all the stuff in A.h

因此，如果您在此处不写#include“ Ah”，会发生什么？在您的C.cpp中，同时使用了A和B（例如，类）。后来，您更改了C.cpp代码，删除了与B相关的内容，但在其中保留了Bh。

如果现在同时包括Ah和Bh，则此时检测到不必要的包含的工具可能会帮助您指出不再需要Bh包含。如果仅按上述方式包含Bh，则在代码更改后，工具/人员很难检测到不必要的包含。

我采用的方法与建议的答案略有不同。

在标头中，始终仅包括最低限度，即通过编译所需的最低限度。尽可能使用前向声明。

在源文件中，包含多少并不重要。我的喜好仍然包括使它通过的最低要求。

对于小型项目，在此处和在其中包含标题都不会有所不同。但是对于大中型项目，这可能会成为一个问题。即使使用最新的硬件进行编译，差异也很明显。原因是编译器仍然必须打开包含的标头并对其进行解析。因此，要优化构建，请应用上述技术（包括最低限度的要求，并使用前向声明）。

尽管有些过时，但是大型C ++软件设计（由John Lakos撰写）详细解释了所有这些。

优良作法是只要编译就不要担心标头策略。

代码的标题部分只是一行代码，在您得到易于解决的编译错误之前，任何人都不要看。我了解对“正确”样式的渴望，但没有一种方法可以真正描述为正确。在每个类中都包含标头很可能会引起恼人的基于订单的编译错误，但这些编译错误也反映出了可以通过仔细编码解决的问题（尽管可以说它们不值得花时间修复）。

是的，一旦您开始着陆，您将遇到那些基于订单的问题friend。

您可以在两种情况下想到该问题。

情况1：您有少量的类彼此交互，例如少于十二个。 您定期添加，删除或以其他方式修改这些标头，这可能会影响它们彼此之间的依赖性。您的代码示例建议这种情况。

标头集足够小，因此解决任何出现的问题并不复杂。任何困难的问题都可以通过重写一个或两个标题来解决。担心头策略会解决不存在的问题。

情况2：您有数十个课程。 有些类代表程序的主干，重写它们的标头将迫使您重写/重新编译大量的代码库。其他类使用此主干来完成任务。这代表了典型的业务环境。标头分布在目录中，您实际上无法记住所有名称。

解决方案：在这一点上，您需要考虑逻辑组中的类，并将这些组收集到标头中，以免您不得不#include一遍又一遍。这不仅简化了工作，而且是利用预编译标头的必要步骤。

您最终#include会上不需要的课，但谁在乎呢？

在这种情况下，您的代码将看起来像...

#include <Graphics.hpp>

struct Entity {
    Texture texture;
    RenderObject render();
}