关于头文件的一切

头文件的害处

• 传递性。头文件可以再包含其他头文件。一个简单的#include<complex>展开后有两万多行代码，一方面造成编译缓慢；另一方面，任何一个头文件的改动一点点代码都会需要重新编译所有直接或间接包含它的元文件。因为Buildtool无法有效判断这个改动是否影响程序语义，保守起见只能把受影响文件全部重新编译一遍
• 顺序性，一个源文件可以包含多个头文件。如果头文件内容组织不当会造成程序的语义跟头文件包含的顺序有关，也跟是否包含一个头文件有关，通常的做法是把头文件分成几类，然后分别按顺序包含着这几类头文件，相同的头文件按文件名顺序排列。这样一方面源码比较简洁，另一方面如果两个人同时修改源码，各自想多包含一个头文件，那么造成冲突的可能性较小，一般应该避免在#include列表的末尾添加新的头文件，这样很快代码的依赖关系就无法管理
• 差异性。内容差异性造成不同源文件看到的头文件不一致，时间差异造成头文件与库文件内容不一致。这说明两个源文件应该用统一的编译选项。如果程序用到了第三方静态库或动态库，除了拿到头文件和库函数，我们还可以拿到当时编译这个库的编译选项，才能安全无误使用这个程序库。

反观现代的编译语言，他们比C++的历史包袱轻得多，模块化做的也比较好。模块化的做法主要有两种：

• 对于解释性语言，impoet的时候直接把对应模块的源文件解析一便（不再是简单地把源文件包含进来）
• 对于编译性语言，编译出来的目标文件里直接包含了足够的元数据，import的时候只需要读目标文件的内容，不需读源文件。

这两种做法都避免了声明预定义不一致的问题，因为在这些语言里声明和定义是一体的。同时这种import手法也不会引入不想要的名字，简化了名字查找的负担，也不用担心import的顺序不同造成代码功能的变化

头文件的使用规则

• 将文件间的编译依赖降至最小
• 将定义是之间的依赖降至最小
• 让class名字，头文件名字，源文件名字直接相关。这样方便源代码的定位。
• 令头文件自给自足