C++头文件的包含顺序

一．《Google C++ 编程风格指南》里的观点

dir2/foo2.h (preferred location — see details below).

C system files.

C++ system files.

Other libraries' .h files.

Your project's .h files.

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

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

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

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

二．《C++编程思想》中的不同观点

假设某个CPP如下：

#include <iostream>

#include "myclass.h"

编译器的分析过程

先分析<iostream>，这个没有错误，OK继续分析

分析"myclass.h"，发现编译错误，终止分析并报错。

如果我们把上述顺序调换，变为：

#include "myclass.h"

#include <iostream>

那么编译器先分析"myclass.h"，发现编译错误，终止分析并报错。

明显可以看出第二种方式能够令分析速度加快。

把最容易出错的头文件(也就是最特殊的头文件)首先#include，这有点像短路求值(if ( 0 && 1 ))，一旦出错，后面就不必再分析。

当然如果所有文件都没有错误，那么两种方式的分析速度会一样快。

综合来看，我们应该以这样的方式来#include头文件：

从最特殊到最一般，也就是，

#include "本类头文件"

#include "本目录头文件"

#include "自己写的工具头文件"

#include "第三方头文件"

#include "平台相关头文件"

#include "C++库头文件"

#include "C库头文件"

预编译头文件：防止同一组头文件在多个CPP文件中被重复分析。

头文件守卫：防止同一头文件在单个CPP文件中被重复分析。

头文件包含顺序有最特殊到最一般：使用短路编译以加快编译出错的过程。

参考：

《C++编程思想第二版》p432

参考文献：

http://www.cnblogs.com/clever101/archive/2011/08/21/2147892.html

http://hi.baidu.com/chunnicunyu/item/dc82651632d1985f2a3e22db