头文件的编译速度更快？

Posted 2021-04-10

我想更深入地了解为什么使用头文件，经过一些研究，我找到了一些令人信服的答案，但在大多数的回答中，人们说它使编译速度更快，但所有这些答案都是模糊的，并没有说头文件究竟如何使编译更容易。

答案

忘掉编译速度的问题。问题是软件的可维护性。

头文件的目的是包含在编译时不同来源所需要的东西，典型的是#定义常量和组成API的函数声明。

另一答案

如果你从头开始编译，将项目划分为头文件并不会提高编译速度。

然而它们使修改代码的速度快了很多。一个项目的编译通常是这样的。首先你把每个文件编译成一个有相对地址的机器代码（所以代码的起始地址是未知的）。然后连接所有其他文件来创建你的项目。

想象一下，你有一个有10.000个文件的项目。如果你只修改了一个文件，当构建项目时，只有这个文件会被编译，然后所有其他文件都会被链接。如果你没有将项目划分为10.000个文件，当构建一个简单的变化时，你将不得不编译所有其他10.000个文件。所以一旦你编译了项目，用这种方法调试会变得相当快。

另外，编译一个文件是一个单线程的程序。所以，你可以通过将几个文件一起编译来实现编译速度的提升。-j 的标志。make 命令可以做到这一点。

另一答案

一些编译器（其实只是MSVC）可以很好地利用预编译头文件。这实际上意味着，如果你在每个编译单元的开始有相同的include文件，那么你可以告诉编译器只处理一次，而对于其他的编译单元，只有在该include之后才开始处理。

如果你看到项目中有一个 stdafx.h 头文件，而这个头文件又拉入了很多其他项目中常用的头文件，那么它就是这样的。

其他编译器如gcc或clang处理源代码的速度要快得多，所以缓存这样一个不完整的表示方式还没有什么好处。

---

除了预编译的头文件，它们也是编译单元之间的通用接口。当谈论带有模板的C++，或者由模板生成过多代码的C语言时，那么在编译阶段将生成的符号的可见性仅限制在该特定的编译单元上，偶尔会有不同的效果。对于在以下环节阶段限制可见性。static 关键字是要用的。

不过现实中这并不影响大多数项目。事实上，对于小项目来说，一个常见的技术其实是在编译前就把所有的编译单元进行合并，这样在编译时就可以消除分离，不需要专门的链接步骤。考虑到合并后的编译单元的静态符号没有冲突，这实际上往往比在头中严格使用最小接口节省了很多编译时间。

根据实际经验估计，一旦单个编译单元中可见的符号超过5-10万个，你就需要出于编译器性能的考虑开始降低可见性。