C / C ++包含头文件的顺序

应该指定包含文件的顺序，即，为什么在一个头之前包含一个头的原因是什么？

例如，系统文件，STL和Boost是否在本地包含文件之前或之后？

我认为没有推荐的顺序，只要可以编译即可！令人讨厌的是，当某些标头要求首先包含其他标头时...这是标头本身的问题，而不是包含顺序的问题。

我个人的喜好是从本地到全局，每个小节都按字母顺序排列，即：

1. 与此cpp文件对应的h文件（如果适用）
2. 来自同一组件的标题
3. 其他组件的标题
4. 系统标题。

我对1.的理由是，它应证明每个标头（为此有一个cpp）都可以在#include没有先决条件的情况下使用d（terminus technicus：标头是“独立的”）。其余的似乎只是从逻辑上流向那里。

要记住的一件大事是，您的标头不应依赖于其他标头被首先包含。确保这一点的一种方法是在其他任何标题之前包含标题。

“使用C ++进行思考”特别提到了Lakos的“大型C ++软件设计”：

通过确保组件的.h文件本身可以进行解析-无需外部提供的声明或定义，可以避免潜在的使用错误。包括.h文件作为.c文件的第一行，可以确保没有关键内容.h文件中缺少组件物理接口固有的信息（或者，如果存在，则在尝试编译.c文件时会立即找到它）。

也就是说，按以下顺序包括：

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

如果任何标题在按此顺序包含时有问题，请修复它们（如果使用的话）或不使用它们。抵制不写干净标题的库。

Google的C ++风格指南提出了几乎相反的说法，实际上根本没有道理。我个人倾向于拉科斯的方法。

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

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"

虽然作为准则，但这是主观的。另一方面，我严格执行这些规则，甚至在某些令人讨厌的第三方开发人员不认同我的愿景的情况下，甚至为“包装”头文件提供包含保护和分组包含的观点：-)

在墙上添加我自己的砖块。

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文件的标题（完整性检查）
• 系统标题
• 第三方标头，按依存关系顺序组织
• 项目标题
• 项目专用标头

还要注意，除了系统头文件之外，每个文件都位于一个具有名称空间名称的文件夹中，这是因为这样更容易跟踪它们。

我建议：

1. 您正在构建的.cc模块的头。（有助于确保项目中的每个标头都没有对项目中其他标头的隐式依赖。）
2. C系统文件。
3. C ++系统文件。
4. 平台/操作系统/其他头文件（例如win32，gtk，openGL）。
5. 项目中的其他头文件。

当然，如有可能，请在每个部分中按字母顺序排列。

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

我敢肯定，在理智的世界中，在任何地方都不推荐这样做，但是我希望按名称长度将系统包括在内，并按相同的长度按词法排序。像这样：

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

我认为，在其他人之前包含您自己的标头是一个好主意，以避免包含顺序依赖的可耻性。

这不是主观的。确保标头不依赖#include于特定顺序的d。您可以确定，添加STL或Boost头的顺序并不重要。

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

推理：source1.h在所有其他文件之前包含之前，确保了它可以独立存在而没有依赖性。如果以后source1.h需要依赖，编译器会立即提醒您将必需的前向声明添加到中source1.h。反过来，这确保了标头可以被其依赖者以任何顺序包括在内。

例：

source1.h

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

source1.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。

从最具体到最不具体，从.cpp的相应.hpp开始（如果存在）。这样，将显示头文件中任何不自足的隐藏依赖项。

使用预编译的标头会使情况变得复杂。解决此问题的一种方法是，不使项目特定于编译器，而是使用项目头之一作为预编译头包含文件。

在C / C ++世界中，这是一个棘手的问题，它包含许多超出标准的元素。

我认为只要编译头文件顺序就不会是一个严重的问题，就像squelart所说的那样。

我的想法是：如果所有这些标头中都没有符号冲突，则任何顺序都可以，并且标头依赖性问题可以在以后通过向有缺陷的.h中添加#include行来解决。

当某些标头根据上面的标头更改其动作（通过检查#if条件）时，才出现真正的麻烦。

例如，在VS2005的stddef.h中，有：

#ifdef  _WIN64
#define offsetof(s,m)   (size_t)( (ptrdiff_t)&(((s *)0)->m) )
#else
#define offsetof(s,m)   (size_t)&(((s *)0)->m)
#endif

现在的问题是：如果我有一个需要与许多编译器一起使用的自定义标头（“ custom.h”），包括一些未offsetof在其系统标头中提供的较旧的编译器，则应在标头中编写：

#ifndef offsetof
#define offsetof(s,m)   (size_t)&(((s *)0)->m)
#endif

而且一定要在用户告诉#include "custom.h" 以后的所有系统头，否则，线offsetof在STDDEF.H将断言宏重新定义错误。

我们祈祷在职业生涯中不再遇到此类情况。