【发布时间】:2019-01-24 13:29:41
【问题描述】:
Google C++ Style Guide 建议按以下顺序将头文件(.h)包含到实现文件(.cpp、.cc)中:
在
dir/foo.cc或dir/foo_test.cc中,其主要目的是实现或测试dir2/foo2.h中的东西,按如下顺序排列您的include:dir2/foo2.h. A blank line C system files. C++ system files. A blank line Other libraries' .h files. Your project's .h files.
如前所述,这样的顺序允许在编译foo-unit 时查看dir2/foo2.h 中省略的依赖项,而不是其他无辜单元。看起来很合乎逻辑。
但是为什么Other libraries' .h files. 和Your project's .h files. 放在列表末尾呢?理论上,也可能缺少依赖项,这些依赖项将通过在之前包含 C system files. 和 C++ system files. 来隐藏。
也许假设应该在相关的实现文件中检测到其他(头)文件问题?在那种情况下,只有头文件的库呢?
换句话说,包含以下顺序:
dir2/foo2.h. A blank line Other libraries' .h files. Your project's .h files. A blank line C system files. C++ system files.
会更好更快地找到隐藏的依赖项吗?
例如,如果我只有需要 <stdio.h> 的标头(但未在该文件中指定)。使用 Google 命令直接或间接包含 <stdio.h> 的可能性高于在最后一步包含系统文件时(正如我之前建议的)。因此,找到隐藏依赖的概率很低。那么,如果在其他 lib/您的项目文件之前包含系统文件,我们将获得什么?
也不清楚,我是否应该在其他(用户定义的)头文件中使用推荐的包含文件顺序。
【问题讨论】:
-
如果遵循相同的指导方针,在构建各自的源文件时应该会出现那些缺少的依赖项。
-
@Someprogrammerdude 请查看帖子更新。
标签: c++ include google-style-guide