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

简单的答案是：不用担心。

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

(当然：制作头文件的方式可能会影响程序性能。但这是糟糕的编程技术的结果，而不是头文件的固有问题)。

常识表明，如果需要，谨慎的做法是只将头文件#include作为头文件。例如，不要#include编译单元(也称为源文件)中只需要几个标准头的每个标准头。实际上，这样做不太可能影响程序速度或内存使用。它可以显著增加编译时间，因为它迫使预处理器读取和处理不需要的头的内容。即便如此，一些编译器实现技术(例如预编译头)也可以减轻这种影响。最后，如果编译单元只依赖于#included三个标准头中的两个，那么担心它们是没有意义的。

#include有许多不必要的头的代码通常不会对程序内存使用、速度或其他性能指标产生任何显著影响。尽管严格来说，这是一个实现质量问题(即编译器有多好？)，但大多数编译器都避免将未使用的声明写入对象文件，因此对可执行文件没有影响。无论是古代还是现代，大多数编译器都能很好地完成这项工作。

注意到上面的警告(避免#include使用实际上不需要的头文件)，因此不值得担心包含"许多"头文件。在C++中，相反的问题(不是#include生成实际需要的头)实际上更糟，因为它会导致任何依赖于该头文件中声明的代码被编译器拒绝。

从技术上讲，可以手动将所需的声明写入到源文件中，而不是包含头。然而，这类事情很快就会变成一个无法维护的烂摊子(如果程序员必须手动在每个源文件中提供所需的声明，而不是包括头文件，请考虑保持10个源文件是最新的)。避免这类问题是头文件存在并被使用的首要原因之一。

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

可执行程序不知道头文件(甚至不知道源文件)。头文件包含在预处理器中(您需要了解预处理器在做什么)。

我有点害怕在程序中添加许多头文件(如ctype.h等)。

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

我很好奇头文件是否真的会对程序的处理速度或内存产生很大影响

不是。然而，大多数库都在头文件中定义它们的接口。通过使用库，您确实增加了程序(或流程)的大小，但您可以利用该库提供的特性和功能。

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

^{(事实并非总是如此：在20世纪50年代和60年代，计算机的成本远高于为其编写程序的开发人员。在20世纪60年代，大型机的成本可能超过其开发人员的终身工资；1987年，我的Sun3/160工作站的成本约为我工资的3年；今天，我强大的Linux台式电脑的成本为我工资两周)}

因为软件的开发和部署成本通常很高(同样，你会发现很多例外)，所以尝试重用软件组件(以降低开发成本)是有意义的。阅读COTS&免费软件。在实践中，选择正确的库是软件开发工作的重要组成部分。阅读有关基于组件的软件工程的信息。当然，算法仍然很重要(请阅读算法简介)，远不止原始代码大小。

最后，目前的(台式机、服务器、笔记本电脑)计算机有相当多的内存(通常至少有8或16G的RAM，而且通常更多)，处理器也相当快。你不太可能担心计算机对你的软件的限制(即二进制可执行文件的大小)。在你的整个职业生涯中，你将要编码的所有组合源代码都比一台典型的计算机所能容纳的要少得多(经验法则是，开发人员每年编写20KLOC，所以在你的一生中，你只会编写一两百万行代码。相比之下，Linux内核有两千多万行代码，可以编译成几兆字节的二进制程序；Firefox浏览器大约有五千万行源代码)。

在小型嵌入式计算领域(例如，类似Arduino的硬件和智能灯泡或连接牙刷等物联网设备)，情况有所不同：代码大小非常重要，因为你可能只有几十千字节的代码内存(你可以达到这个极限)。然而，硬件非常便宜，即使在廉价的嵌入式系统中，使用更强大的硬件(类似RaspberryPi)也更有意义；因此，趋势是，即使对于嵌入式计算，代码大小也不那么重要(但也有例外：RFID芯片和智能卡仍然非常受限于代码大小)。

根据经验，您不应该担心使用许多头文件以及现有的软件组件和库(从专业角度讲，您将需要使用大量头文件和库)。在一些非常具体的情况和行业(嵌入式计算的低端领域)，代码大小仍然很重要，你的雇主会接受花费劳动力成本来降低它。换句话说，在大多数情况下，软件开发成本(和时间)占主导地位。在某些情况下(嵌入式计算)，它们可能不是，其他约束可能更重要。