C++ 头文件顺序和隐含依赖

今天编写一个程序，拷贝另外一个文件的头文件时，没有注意头文件之间的内在依赖关系，导致编译出错，浪费了不少时间去定位和分析，才发现是头文件顺序不对导致的编译问题，这也给自己以后编写可靠代码时提供了一个主意项，准备参考google C++编程风格的头文件顺序。

google C++编程风格对头文件的包含顺序作出如下指示：

（1）为了加强可读性和避免隐含依赖，应使用下面的顺序：C标准库、C++标准库、其它库的头文件、你自己工程的头文件。不过这里最先包含的是首选的头文件，即例如a.cpp文件中应该优先包含a.h。首选的头文件是为了减少隐藏依赖，同时确保头文件和实现文件是匹配的。具体的例子是：假如你有一个cc文件（Linux平台的cpp文件后缀为cc）是google-awesome-project/src/foo/internal/fooserver.cc，那么它所包含的头文件的顺序如下：

#include "foo/public/fooserver.h"  //首选的头文件放在第一位

#include <sys/types.h>
#include <unistd.h>

#include <hash_map>
#include <vector>
#include "base/basictypes.h"
#include "base/commandlineflags.h"
#include "foo/public/bar.h"

例如:

//A.h中：

struct BS bs;

...

//B.h中：

struct BS{....};

//在A.c中//这样会报错

#include A.h

#include B.h

//先包含B.h就可以

#include B.h#include A.h

<span style="font-family: "microsoft yahei"; background-color: rgb(255, 255, 255);"><span style="font-size:18px;">这样就叫”隐藏依赖”。如果先包含A.h就可以发现隐藏依赖，所以各种规范都要求自身的头文件放在第一个，就能发现隐藏依赖。解决办法就是在A.h中包含B.h，而不是在A.c中再包含。</span></span>

（2）在包含头文件时应该加上头文件所在工程的文件夹名，即假如你有这样一个工程base，里面有一个logging.h，那么外部包含这个头文件应该这样写： 
#include “base/logging.h”，而不是#include “logging.h”

我们看到的是这里《Google C++ 编程风格指南》倡导的原则背后隐藏的目的是：

1. 为了减少隐藏依赖，同时头文件和其实现文件匹配，应该先包含其首选项（即其对应的头文件）。

2. 除了首选项外，遵循的是从一般到特殊的原则。不过我觉得《Google C++ 编程风格指南》的顺序：C标准库、C++标准库、其它库的头文件、你自己工程的头文件中漏了最前面的一项：操作系统级别的头文件，比如上面的例子sys/types.h估计不能归入C标准库，而是Linux操作系统提供的SDK吧。因此我觉得更准确的说法应该是：OS SDK .h , C标准库、C++标准库、其它库的头文件、你自己工程的头文件。

3. 之所以要将头文件所在的工程目录列出，作用应该是命名空间是一样的，就是为了区分不小心造成的文件重名。

参考文献

[1]http://www.cnblogs.com/clever101/archive/2011/08/21/2147892.html 
[2]http://www.cnblogs.com/frydsh/p/3466660.html