问我正在编译一个程序,但似乎缺少它所需的一个头文件。有人能发我一份副本吗?
答这取决于“丢失”的是什么类型的头文件,情况会有所不同。
如果丢失的头文件确实是标准文件(即由 ANSI C 标准定义的,例如<stdio.h>),那么你的编译器有问题。要么是编译器未正确安装,要么是你的项目某种程度上未配置为查找标准头文件。你需要联系你的供应商,或了解你特定编译器的人寻求帮助。
对于非标准头文件,情况就复杂得多。有些头文件(例如<dos.h>)完全是系统或编译器特定的。有些则完全不必要,应该被其标准等效文件替换。(例如,非标准的<malloc.h>和<memory.h>,而是应分别#include <stdlib.h>和<string.h>。)另一些头文件,例如与流行的附加库相关的头文件,可能是相当可移植的。
如果丢失的头文件是特定于操作系统的,例如<sgtty.h>, <sys/stat.h>, <netinet/in.h>或<dos.h>19.1、19.4、19.12b 和 19.40c。
如果丢失的头文件是用于某个外部的、附加的、第三方库的,请在获得该库的地方查找该头文件。如果你有一些源代码 #includes 了看起来像是附加头文件但你没有的头文件,你很可能也没有这个库,你需要两者兼有。请参阅问题 13.25;另请参阅问题 18.16。
如果头文件是你要编译的程序所特有的(即属于该程序一部分),你的搜索显然应该从你找到该程序的地方开始。(同样,请参阅问题 18.16。)
然而,一般来说,要求别人“发一份副本”给你一个丢失的头文件不太可能产生积极的结果。标准头文件的存在部分是为了提供适合你的编译器、操作系统和处理器的定义。你不能仅仅拿别人的头文件副本并期望它能工作,除非那个人使用的环境完全相同。非标准头文件——例如特定于特定操作系统或第三方库的头文件——通常并没有更具可移植性;特定于操作系统的头文件很可能非常特定于某个操作系统版本和发行版,而第三方头文件则可能同样绑定到某个特定版本的库。
底线是,网络上的随机一个人不太可能给你发送你(似乎)需要的头文件的可用副本。你可能确实遇到了可移植性问题(参见第 19 节),或者编译器问题(在这种情况下,你可以询问你的编译器供应商为什么没有提供该文件,或者发送一个替换副本)。否则(如果该头文件是第三方或应用程序特定的),请参阅问题 18.16。