头文件是否会影响内存或程序的处理速度？

Question

我有点害怕在我的程序中添加许多头文件（比如ctype.h等）。

我很好奇头文件是否真的对程序的进程速度或内存有很大的影响

Answer 1

简短的回答：不要担心。

程序中的代码和数据（即它的作用）是程序性能特征（速度，内存使用等）的主要驱动因素。该代码的组织（例如，头文件中的声明用于重用，包括哪些标准头文件）几乎没有影响。

（当然：有可能以一种对程序性能产生影响的方式制作头文件。但这是编程技术不好的结果，而不是头文件的内在问题。）

常识表明，如果需要，只有#include头文件是谨慎的。例如，不要#include编译单元（也就是源文件）中的每个标准头，只需要其中的几个。实际上，做这样的事情不太可能影响程序速度或内存使用情况。它可以显着增加编译时间，因为它会强制预处理器读取和处理不需要的标头内容。即使这样，一些编译器实现技术（例如预编译头）也可以减轻这种影响。最后，如果编译单元仅依赖于其中两个标题，那么就没有必要担心会有#include三个标准标题。

#include多个标头不必要的代码通常不会对程序内存使用，速度或其他性能指标产生任何显着影响。虽然严格来说，关注实现的质量（即编译器有多好？），但大多数编译器都避免将未使用的声明写入目标文件，因此对可执行文件没有影响。大多数编译器 - 包括古代编译器和现代编译器 - 都做得不错。

注意上面的警告（避免#include实际上不需要的标题），因此不值得担心包括＆＃34;许多＆＃34;头文件。在C ++中，相反的问题（不是#include实际需要的标题）实际上更糟糕 - 因为它会导致任何依赖于该头文件中的声明的代码被编译器拒绝。

技术上可以手工编写所需的声明到源文件中，而不是包含标题。然而，这种事情很快变成了难以维护的混乱（考虑到保持10个源文件是最新的，如果程序员必须在每个文件中手动提供所需的声明，而不是包括标题）。避免这类问题是头文件存在并首先被使用的原因之一。

Answer 2

头文件是源代码级别的人工制品。

可执行程序不了解头文件（甚至源文件）。头文件包含在preprocessor中（您需要了解预处理器正在做什么）。

  

我有点害怕在我的程序中添加许多头文件（比如ctype.h等）。

你为什么害怕？通常，使用许多头文件会影响编译时间（您可以负担得起）。

  

我很好奇头文件是否真的对程序的进程速度或内存有很大的影响

不是真的。但是，大多数libraries正在头文件中定义其接口。通过使用库，您确实可以增加程序（或程序）的大小，但您可以利用该库提供的功能和特性。

另请注意，今天，开发时间通常比执行时间更重要。在许多情况下，开发成本（劳动力成本）比运行软件的计算机的成本更重要（当然，这个经验法则也有例外）。软件的成本高于运行它的硬件（同样，也有例外）

^{（这并非总是如此：在20世纪50年代和60年代，计算机的成本比开发人员编写程序的成本要高得多。在20世纪60年代，大型机的成本可能超过其开发人员的终身工资; 1987年我的Sun3 / 160工作站的工资大约是我工资的3年;今天，我功能强大的Linux桌面PC的工资是我工资的两周）}

因为软件的开发成本很高（再次，你会发现很多例外）并且已经部署，因此尝试重用软件组件（降低开发成本）是有意义的。阅读COTS＆amp; free software。在实践中，选择正确的库是软件开发工作的重要组成部分。阅读component-based software engineering。当然，算法仍然很重要（阅读Introduction to Algorithms），远远超过原始代码大小。

最后，当前（台式机，服务器，笔记本电脑）计算机拥有相当多的内存（至少通常为8或16千兆字节的RAM，而且往往更多）并且具有相当快的处理器。您极不可能担心软件的计算机限制（即二进制可执行文件大小）。您在整个职业生涯中编码的所有组合源代码远远少于典型计算机所能适用的代码（经验法则是开发人员每年编写20KLOC，因此在您的一生中，您只需编写一个或者两百万行代码。相比之下，Linux内核超过二千万行代码并编译成几兆字节的二进制程序; Firefox浏览器大约有五千万行源代码。）

在小型embedded计算区域（例如Arduino类似硬件和IoT设备（如智能灯泡或连接的牙刷））情况有所不同：代码大小非常重要，因为你可能只有几十千字节的代码内存（你可以达到这个限制）。但是，硬件非常便宜，即使在廉价的嵌入式系统中，使用功能更强大的硬件（RaspberryPi）也更有意义;所以趋势是代码大小更少，即使对于嵌入式计算也是如此（但存在例外：RFID芯片和smart cards仍然非常受限于代码大小。）

根据经验，您不应该担心使用许多头文件和现有的软件组件和库（并且专业地，您将被要求使用它们中的很多）。在一些非常具体的案例和行业（嵌入式计算的低端领域）中，代码大小仍然很重要，您的雇主将接受花费人工成本来减少代码大小。 换句话说，在大多数情况下，软件开发成本（和时间）占主导地位。在某些情况下（嵌入式计算），它们可能不是，而其他约束可能更重要。