在源文件和头文件中包含指令顺序[关闭]答案

【问题标题】：Include directives order in source file and in header file [closed]在源文件和头文件中包含指令顺序[关闭]
【发布时间】：2021-04-29 12:41:38
【问题描述】：

#include 指令的推荐顺序是什么？我在 C++ Core Guidelines

中找不到任何答案

例如，它们是否应该这样排序：

#include "OtherHeaderInCurrentLib.h"
#include <third_party_library/header.h>
#include <iostream>

或者他们应该像这样订购：

#include <iostream>
#include <third_party_library/header.h>
#include "OtherHeaderInCurrentLib.h"

在源文件中列出的推荐顺序和在头文件中列出的推荐顺序有什么区别吗？

【问题讨论】：

按字母顺序发音
我认为如果您的标题包含他们需要的所有内容，这主要是用户偏好。
“我怀疑像 ADL 这样的语言特性严重依赖声明顺序” 这是一个明显的迹象，表明这些标头以错误的方式编写。顺序根本不重要。客户应该只#include 实际需要的东西。
对于我在 msvc 上使用预编译头文件（超过 2 个十年），它的行为与源文件的第二个示例非常相似。我的意思是在 pch.h 中，我通常包含系统头文件，可能还有第三方头文件，但随后必须将 pch.h 作为您的第一个包含，因为这是您的源文件的要求，因为预编译的头文件实现让编译器忽略#include "pch.h"以上的所有行
这是注定要结束意见的，但我要给我的。把你的放在第一位。它极大地有助于避免基于消费的包含依赖。 IE。如果您的标头需要<string>，它应该包括<string>。如果您不这样做，但将其放在具有#include <string> 的 cpp 中的一堆包含之后，则该事故被隐藏...直到您在其他地方使用它，而消费 cpp 在您之前没有包含 <string>标头，现在您想知道 wtf .. 这以前有效，为什么现在不行？简而言之，我同意 eerorika。

【解决方案1】：

在第一方自定义标头之前包含标准或第三方标头的一个缺点是很容易意外依赖您忘记直接包含的标头。如果由于不相关的更改而删除了间接包含，或者将自定义标头包含在没有缺少的依赖项的上下文中，这将导致问题。

在典型的 x.hpp 中，x.cpp“模块”结构（不要与 C++20 模块混淆），包括 x.hpp 作为 x.cpp 中的第一个头文件，确保所有此类头文件都具有至少一个翻译单元首先包含它们，避免在 x.hpp 中未检测到缺失包含的问题。

除此之外，保持包含的顺序是一个好主意，以便一目了然地了解依赖关系。按图书馆分组，并按字母顺序排列组是保持包含顺序的典型方法。

【讨论】：

fwiw，谷歌指南建议将您的项目标题放在最后：google.github.io/styleguide/… 认为将foo.h 放在foo.cpp 的首位就足以使其在缺少包含的情况下中断，而其他人使用@987654324 @ 不应该为错误而烦恼。
@largest_prime_is_463035818 这就是我一直在寻找的，一些行业标准推荐以及选择背后的原因。不幸的是，他们必须像往常一样匆忙结束任何问题才能获得他们心爱的代币，否则我会选择你的答案。
@largest_prime_is_463035818 这是一个合理的论点。他们似乎没有解释为什么在标准标题之后包含其余的自定义标题是有利的。据我所知，这没关系。
@nyarlathotep108 这不是行业标准。这是一份 Google 风格指南。
@nyarlthotep108 是的，考虑到 google 指南的编写考虑了非常具体的代码库。当您必须以某种方式管理数百万行代码时，您将面临不同的问题。有时我会在他们的指导方针中找到一个要点，我根本不想在我的项目中应用（但我理解他们为什么将其放在指导方针中）