C/C++包括头文件顺序

Question

应该指定哪些顺序包含文件,即将一个标题包含在另一个标题之前的原因是什么？

例如,系统文件,STL和Boost是在本地包含文件之前还是之后运行？

Answer 1

我不认为有推荐的订单,只要它编译!令人讨厌的是,当某些标头需要首先包含其他标头时...这是标题本身的问题,而不是包含的顺序.

我个人的偏好是从本地到全球,每个子部分按字母顺序排列,即:

1. h文件对应于此cpp文件(如果适用)
2. 来自同一组件的标题,
3. 来自其他组件的标题,
4. 系统标题.

我的理由是,它应该证明每个标题(有一个cpp)都可以#include没有先决条件.其余的似乎从那里开始逻辑流动.

Answer 2

要记住的重要一点是,您的标头不应该依赖于首先包含的其他标头.确保这一点的一种方法是在任何其他标头之前包含您的标头.

"用C++思考"特别提到了这一点,引用了Lakos的"大规模C++软件设计":

通过确保组件的.h文件自行解析,可以避免潜在的使用错误 - 没有外部提供的声明或定义......包含.h文件作为.c文件的第一行确保没有关键部分.h文件中缺少组件物理接口固有的信息(或者,如果有的话,只要您尝试编译.c文件就会发现它).

也就是说,按以下顺序包括:

1. 此实现的原型/接口标头(即与.cpp/.cc文件对应的.h/.hh文件).
2. 根据需要,来自同一项目的其他标头.
3. 来自其他非标准非系统库的标题(例如,Qt,Eigen等).
4. 来自其他"几乎标准"库的标题(例如,Boost)
5. 标准C++标头(例如,iostream,功能等)
6. 标准C头文件(例如,cstdint,dirent.h等)

如果任何标题包含在此顺序中的问题,请修复它们(如果您的)或不使用它们.阻止不编写干净标头的库.

谷歌的C++风格指南认为几乎相反的,跟真的没有道理的; 我个人倾向于赞成Lakos方法.

Answer 3

我遵循两个简单的规则来避免绝大多数问题:

1. 所有的头(实际上任何的源文件)应该包括他们需要什么.他们应该不依赖于他们的用户,包括东西.
2. 作为附件,所有标题都应该包含警戒,这样就不会因为过于雄心勃勃地应用上述规则1而多次包含它们.

我也遵循以下准则:

1. 首先包含带有分界线的系统头(stdio.h等).
2. 按逻辑分组.

换一种说法:

#include <stdio.h>
#include <string.h>

#include "btree.h"
#include "collect_hash.h"
#include "collect_arraylist.h"
#include "globals.h"

虽然,作为指导方针,这是一个主观的事情.另一方面,我严格执行规则,甚至提供包含警卫的"包装"头文件和分组包括如果一些讨厌的第三方开发人员不订阅我的愿景:-)

Answer 4

把我自己的砖添加到墙上.

1. 每个标题都需要自给自足,只有在首次包含至少一次时才能进行测试
2. 不应该通过引入符号(宏,类型等)错误地修改第三方标题的含义

所以我通常会这样:

// myproject/src/example.cpp
#include "myproject/example.h"

#include <algorithm>
#include <set>
#include <vector>

#include <3rdparty/foo.h>
#include <3rdparty/bar.h>

#include "myproject/another.h"
#include "myproject/specific/bla.h"

#include "detail/impl.h"

每个组用下一个空白行分隔:

• 首先对应于此cpp文件的标题(健全性检查)
• 系统标头
• 第三方标头,按依赖顺序组织
• 项目标题
• 项目私有标题

另请注意,除了系统标头之外,每个文件都位于具有其命名空间名称的文件夹中,因为它更容易以这种方式跟踪它们.

Answer 5

我很确定这在理智的世界中的任何地方都不是推荐的做法,但我喜欢将系统包含在文件名长度中,并在相同长度内排序.像这样:

#include <set>
#include <vector>
#include <algorithm>
#include <functional>

我认为在其他人之前包含你自己的标题是个好主意,以避免包含顺序依赖的耻辱.

Answer 6

我建议:

1. 您正在构建的.cc模块的标头.(帮助确保项目中的每个标头都没有对项目中其他标头的隐式依赖关系.)
2. C系统文件.
3. C++系统文件.
4. 平台/ OS /其他头文件(例如win32,gtk,openGL).
5. 项目中的其他头文件.

当然,在可能的情况下,每个部分的字母顺序.

始终使用前向声明以避免#include头文件中不必要的s.

Answer 7

这不是主观的.确保标题不依赖#include于特定顺序.您可以确定包含STL或Boost标头的顺序无关紧要.

Answer 8

首先包含与 .cpp 对应的标头...换句话说，应该在包含其他任何内容之前source1.cpp包含。source1.h我能想到的唯一例外是当使用带有预编译标头的 MSVC 时，在这种情况下，您必须在stdafx.h其他任何内容之前包含。

推理：将 包含source1.h在任何其他文件之前可确保它可以独立存在而无需依赖。如果source1.h稍后出现依赖项，编译器将立即提醒您将所需的前向声明添加到source1.h. 这反过来又确保了标头可以由其相关项以任何顺序包含。

例子：

源1.h

class Class1 {
    Class2 c2;    // a dependency which has not been forward declared
};

源1.cpp

#include "source1.h"    // now compiler will alert you saying that Class2 is undefined
                    // so you can forward declare Class2 within source1.h
...

MSVC 用户：我强烈建议使用预编译头。因此，将#include标准标头（以及其他永远不会更改的标头）的所有指令移至stdafx.h.