C++标题顺序

标头/ cpp文件中应标头的顺序是什么？显然,后续标题所需的那些应该更早,特定于类的标题应该在cpp范围内而不是标题范围,但是是否有一个集合顺序约定/最佳实践？

1> Mykola Golub..：

---

在头文件中,您必须包含所有标头以使其可编译.并且不要忘记使用前向声明而不是某些标头.

在源文件中:

相应的头文件

必要的项目标题

第三方库标题

标准库头

系统标题

按此顺序,您将不会错过任何忘记自己包含库的头文件.

---

我认为"必要的项目标题"应该在两个项目上分开: - 来自同一个lib的项目标题; - 来自其他项目库的标题(按照下面的大多数常见项目库标题的顺序,而不是一些特殊的项目库标题)

---

我真的很喜欢你的订购.这样,标头不依赖于其他标头来包含它们的依赖.

2> Daniel Earwi..：

---

好的做法:每个.h文件都应该有一个.cpp,首先包含.hpp.这证明任何.h文件都可以放在第一位.

即使标头不需要实现,也可以创建一个仅包含该.h文件的.cpp,而不是其他内容.

这意味着您可以按照自己喜欢的方式回答问题.你把它们包含在哪个顺序并不重要.

欲了解更多伟大的秘诀,尝试这本书:大型C++软件设计 -这是一种耻辱,它是如此昂贵,但它实际上是对C++源代码布局的生存指南.

---

更容易自动化测试:只需编译(-c)每个头文件(是的,g ++ -c blah.h)并确保它编译.然后,您可以将目标文件丢弃.

---

您也可以使用VC++:cl.exe/EHsc/TP/c blah.h

3> Luc Touraill..：

---

在头文件中,我倾向于首先放置标准头,然后是我自己的头(两个列表按字母顺序排序).在实现文件中,我首先将标题对应(如果有的话),然后是标准标题和其他依赖标题.

除非您充分利用宏,否则顺序并不重要#define; 在这种情况下,您必须检查您定义的宏不会替换以前包含的宏(当然,除非您想要的是这样).

关于这个声明

后续标题所需的那些应该更早

标头不应该依赖于之前包含的其他标头!如果它需要标题,它只包括它们.标题保护将阻止多重包含:

#ifndef FOO_HEADER_H
#define FOO_HEADER_H
...
#endif

---

编辑

自从我写了这个答案后,我改变了在代码中对include指令进行排序的方式.现在,我尝试始终按标准化的顺序放置标题,因此我的项目的标题首先出现,然后是第三方库标题,然后是标准标题.

例如,如果我的一个文件使用了我编写的库,Qt,Boost和标准库,我将按如下顺序排列包含:

//foo.cpp
#include "foo.hpp"

#include 
// other headers related to my_library

#include 
// other Qt headers

#include  // Boost is arguably more standard than Qt
// other boost headers

#include 
// other standard algorithms

我这样做的原因是在我自己的标题中检测缺少的依赖项:让我们假设my_library.hpp使用std::copy但不包括.如果我把它给以后的foo.cpp,这个缺失的依赖会被忽视.相反,根据我刚刚提出的顺序,编译器会抱怨std::copy尚未声明,允许我更正my_library.hpp.

在每个"库"组中,我尝试按字母顺序排列include指令,以便更容易地找到它们.

另一方面,一个好的做法是最大限度地限制头文件之间的依赖关系.文件应包含尽可能少的标头,尤其是头文件.实际上,您包含的标头越多,在更改内容时需要重新编译的代码越多.限制这些依赖关系的一个好方法是使用前向声明,这在头文件中通常是足够的(请参阅何时可以使用前向声明？).

4> Igor Oks..：

---

Google C++样式指南,名称和包含顺序:

在dir/foo.cc中,其主要目的是在dir2/foo2.h中实现或测试内容,请按以下方式订购包含:

dir2/foo2.h(首选位置 - 见下面的详细信息).

C系统文件.

C++系统文件.

其他库的.h文件.

你的项目的.h文件.

---

是啊但ggl风格指南有一些令人讨厌的东西:)