C++ #include 的排序答案

【问题标题】：Ordering of C++ #include'sC++ #include 的排序
【发布时间】：2018-03-22 15:20:04
【问题描述】：

这是来自Google's C++ style guide 的关于#include 的部分：

在dir/foo.cc或dir/foo_test.cc中，其主要目的是实现或测试 dir2/foo2.h 中的内容，按如下顺序排列您的包含：
dir2/foo2.h.
A blank line
C system files.
C++ system files.
A blank line
Other libraries' .h files.
Your project's .h files.
请注意，任何相邻的空白行都应折叠。

使用首选顺序，如果 dir2/foo2.h 省略了任何必要的包括， dir/foo.cc 或 dir/foo_test.cc 的构建将中断。因此，此规则确保构建中断首先出现在人们面前处理这些文件，而不是为其他包中的无辜者。

最后一行没看懂：

因此，此规则确保构建中断首先显示给人们处理这些文件，而不是为其他包中的无辜者。

有人能解释一下如何将dir2/foo2.h 放在首位会导致“良好”的构建中断，以及将dir2/foo2.h 放在最后会如何导致“糟糕”的构建中断？

【问题讨论】：

我认为他们只是意味着从事它工作的人可能已经包含了一个包含，所以即使它不在目标文件包含中，它也适用于他们..但可能会破坏你您只包含该模块的标头...并且通过这种方式对其进行结构化，它将破坏维护者，因为它们首先包含 dir2/foo2.h
这实际上是在您的标头中隐藏缺少的包含，因此这似乎不是一个好主意。
不小心依赖出现在另一个 .h 文件中的声明是一个非常常见的错误。把它放在第一位你不会注意到。标准 C++ 有这个问题，iostream 相当臭名昭著。
如果您的标头忘记包含相关标头，那么您的测试程序就是垃圾。与其提出晦涩难懂的编码风格规则，不如改进单元测试代码的方式。它是行业事实上的标准，包括进入 header 文件而不是其他任何地方，因此代码的用户可以轻松地获得所有代码依赖项的概述。他们不应该去挖掘*.c* 文件——他们甚至可能无法访问它们！使用带有良好单元测试的行业事实标准编码，而不是带有糟糕单元测试的 Google-mumbo-jumbo 标准。
@Lundin：“这是行业事实上的标准，包括进入头文件而没有其他地方”什么？绝对不是这种情况，除非您想要疯狂的编译时间和增量构建，从而重建您的整个应用程序。

标签： c++ c header-files

【解决方案1】：

在dir2.h 中，您忘记包含X.h。然后在当前文件中包含：

X.h
dir2.h

这会编译得很好。然后其他人在其他地方包含dir2.h，他们最终会出现源自dir2.h 的编译错误，即使他们从未更改过该文件中的任何内容......

如果你有正确的顺序，你应该在第一次包含dir2.h时得到错误。

【讨论】：

【解决方案2】：

“好的”构建中断是指对进行重大更改的人造成的中断。因为那个人可以修。如果那个人没有注意到这些重大更改，因为包含文件已排序，因此它确实为他编译了很偶然的机会，那么它将被释放。

“糟糕”的构建中断是指发布的版本中断了该代码用户的构建。

【讨论】：