#include 包含的头文件已经包含的头文件是常见的做法吗？ [复制]

Question

假设我们有一个头文件A.h，它依赖于B.h 和C.h 中声明的内容。 B.h 也依赖于 C.h，因此包含它。 在这种情况下，我们不需要在A.h 中包含C.h，没有它它也能正常编译。

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

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

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

Answer 1

通常的做法——也是我建议的经验法则——是所有标题都应该是独立的。

换句话说，如果A.h 中的某些东西只有在B.h 是#included 时才能编译，那么A.h 应该是#include "B.h"。这样可以避免在需要使用 A.h 时强制执行其他代码

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

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

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

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

Answer 2

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

没错。为什么要冒险？

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

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

将其重构为更小的模块。

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

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

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