#include 包含的头文件已包含的头文件是否常见?

Is it common practive to #include header files already included by included header files?

本文关键字：文件包含常见 #include 是否更新时间：2023-10-16

假设我们有一个头文件A.h它依赖于B.h和C.h中声明的内容。B.h也取决于C.h，因此包括它。在这种情况下，我们不需要在A.h中包含C.h，如果没有它，它可以很好地编译。

但我想知道在这些情况下最好的行动方案是什么。如果B.h以某种方式改变并且不再依赖于C.h，A.h就会中断。

另一方面，如果我认为这一点到最后，那么重新包含每个依赖项似乎是不必要/不切实际的。

我有一个常见的情况是标准库。在几乎所有的头文件中，我都必须包含<stdint.h>和<stdbool.h>。我经常跳过这个，因为它们已经包含在其中一个依赖项中，但这总是感觉有点武断。

如果 B.h 以某种方式发生变化并且不再依赖于 C.h，A.h 就会中断。

完全。为什么要冒险？

另一方面，如果我认为这一点到最后，那么重新包含每个依赖项似乎是不必要/不切实际的。

如果不切实际，则文件具有太多依赖项，并且可能太大。

将其重构为更小的模块。

我有一个常见的情况是标准库。在几乎所有的头文件中，我都必须包含<stdint.h>和<stdbool.h>。我经常跳过这个，因为它们已经包含在其中一个依赖项中，但这总是感觉有点武断。

我承认，当我知道我的一个标头(明确定义为将我需要的类型纳入范围)已经这样做时，有时会跳过这些标头。它不太可能被重构，因为它具有这些标头，而不是出于其他可能消失的依赖项。

但是，归根结底，在您需要的地方包含<stdint.h>和<stdbool.h>并没有错。老实说，我很惊讶你发现"几乎所有[你的]头文件"都需要它们。

常见的做法 - 以及我建议的经验法则 - 是所有标头都应该是独立的。

换句话说，如果A.h中的某些内容只有在#includedB.h时才能编译，那么A.h应该#include "B.h"。这避免了在需要使用A.h时强制使用其他代码

#include "B.h"
#include "A.h"

这是递归的。每个包含的文件都应该是独立的。它也适用于您的标头，包括标准标头。

为了处理多次包含标头的潜在问题，还应在标头中使用防护装置。

像任何经验法则一样，在某些情况下它不适用。但这些在实践中相对不常见。