比方说，我们有一个头文件A.h，它取决于B.h和C.h中声明的内容。 B.h也依赖于C.h，因此也包含它。
在这种情况下，我们不需要在C.h中包含A.h，并且没有它也可以编译。
但是我想知道在这些情况下最好的行动方案是什么。如果B.h有所改变并且不再依赖C.h，则A.h将会中断。
另一方面，如果我认为到最后，重新包含所有单个依赖关系似乎是不必要的/不切实际的。
我常见的情况是标准库。在几乎所有的头文件中，我都必须包含<stdint.h>和<stdbool.h>。我经常跳过它，因为它们已经包含在其中一个依赖项中，但这总是让人感到任意。
答案 0 :(得分：5)
如果B.h有所改变并且不再依赖于C.h，则A.h将会中断。
完全正确。为什么要抓住机会？
另一方面，如果我认为到最后，重新包含所有单个依赖关系似乎是不必要的/不切实际的。
如果不切实际，则您的文件具有过多的依赖关系，并且可能太大。
将其重构为较小的模块。
我常见的情况是标准库。在几乎所有的头文件中，我都必须包含
<stdint.h>和<stdbool.h>。我经常跳过它，因为它们已经包含在其中一个依赖项中，但这总是让人感到任意。
我承认，当我知道自己的一个标头（明确定义为将所需的类型带入范围）时，有时会跳过这些操作。不太可能进行重构，因为它具有这些标头出于这个原因，而不是因为某些其他依赖项可能会消失。
但是，最终，在需要的地方包含<stdint.h>和<stdbool.h>并没有错。老实说，我惊讶地发现您在“几乎所有[您的]头文件中”都需要它们。
答案 1 :(得分：3)
通常的做法-我建议的经验法则是所有标头都应该是独立的。
换句话说，如果A.h中的某些内容仅在B.h d时才可以编译，则#include应该A.h。这样可以避免在需要使用#include "B.h"进行操作时强制使用其他代码
A.h那是递归的。每个包含的文件应该是独立的。它也适用于您的标头，包括标准标头。
要处理多次包含标头的潜在问题，还应在标头中使用防护措施。
就像任何经验法则一样，在某些情况下它并不适用。但是这些在实践中并不常见。