头文件的部分规则：重定义相关.docx

如何在C语言中自己写头文件一些初学C语言的人，不知道头文件（*.h文件）原来还可以自己写的。只知道调用系统库 函数时，要使用#include语句将某些头文件包含进去。其实，头文件跟.C文件一样，是可以自己写的。头文件是一种文本文件，使用文本编辑器将代码编写好之后，以扩展名.h保存就行了。头文件中一般放一些重复使用的代码，例如函数声明，变量声明，常数定义，宏的定义等等。当使用#include语句将头文件引用时，相当于将头文件中所有内容，复制到#include处。为了避免因为重复引用而导致的编译错误，头文件常具有 #ifndef LABEL#define LABEL /代码部分#endif的格式。其中，LABEL为一个唯一的标号，命名规则跟变量的命名规则一样。常根据它所在的头文件名来命名，例如，如果头文件的文件名叫做hardware.h，那么可以这样使用：#ifndef _HARDWARE_H_#define _HARDWARE_H_ /代码部分#endif这样写的意思就是，如果没有定义_HARDWARE_H_，则定义_HARDWARE_H_，并编译下面的代码部分，直到遇到#endif。这样，当重复引用时，由于_HARDWARE_H_已经被定义，则下面的代码部分就不会被编译了，这样就避免了重复定义。另外一个地方就是使用include时，使用引号与尖括号的意思是不一样的。使用引号(“”)时，首先搜索工程文件所在目录，然后再搜索编译器头文件所在目录。而使用尖括号()时，刚好是相反的搜索顺序。假设我们有两个文件名一样的头文件hardware.h，但内容却是不一样的。一个保存在编译器指定的头文件目录下，我们把它叫做文件I；另一个则保存在当前工程的目录下，我们把它叫做文件II。如果我们使用的是#include ，则我们引用到的是文件I。如果我们使用的是#include “hardware.h”，则我们引用的将是文件II。笔者以前就遇到过一个同事问，为什么他修改了那个头文件里面的内容，好象跟没有修改一样？就是因为他有两个一样的头文件（就像我们刚描述的那样），他是使用#include引用的，而他修改时，却是当前工程所在的目录下的那个文件。一.RULE1: 每个头文件都用以下宏包起来，防止被其他文件多次包含。#ifndef _FILENAME_H_#define _FILENAME_H_（文件内容）#endif /_FILENAME_H_RULE2: 在定义一个宏的时候，考虑是否需要检测是否已经被定义过。#ifndef MACRO_NAME#define MACRO_NAME MACRO_VALUE#endifRULE3：头文件中不要去定义全局变量，也就是说头文件中的所有语句不能涉及实际内存的分配。对于RULE1，基本上大家都会这么做，当然也可以用pragma once来代替，只是pragma once的通用性不好，所以大家大多选择比较麻烦一点的RULE1中的做法。RULE1不是我想说的重点。RULE2主要是为了防止宏重定义。在同一个工程中，尤其是一较大的工程中，同一个名字的宏在多个文件被定义是很正常的，比如BREW中RELEASEIF往往在多处被定义。在VC的编译器中，即使重定义也不会报错，甚至连Warning都没有，但是TCC会作为Error来处理。举例：a.h中定义了宏A，b.h中也定义了宏A，他们都没有用ifndef包起来。然后某个源文件同时包含了这两个文件。对于严格的编译器来说，会出现重定义的错误，而对于检查较松的编译器，后者的定义会覆盖前者的定义（有的时候不同地方对同一个宏的定义不同）。有的时候，某些头文件我们需要包含进来，但是我们不关心那些头文件有没有已经定义了自己想要定义的宏或者自己想要定义的宏名被那些头文件定义成了什么样子，我们可以先undef掉那个宏，然后再定义自己的宏，这样可以保证自己用的宏是自己想要的定义。用RULE2的做法确实存在这样一个问题，我们不能确定自己用的宏是什么样子的（和包含的头文件以及它们的顺序有关系，这意味着本来都正常的代码，忽然有一天你又把另外一个头文件包含进来，结果这个宏的定义可能就不再是原来的那个了）。如果需要确认，可以让编译器生成预处理后的文件查看，不过一般情况下不需要这么做。今天有个同事碰到了这样一个问题，让我过去帮他看看：我看到的错误是说某个头文件的某个宏重定义了。据他描述是因为他在某个C源文件里包含了多个头文件导致的。可是这些被他包含进来的头文件中却没有那个提示出错的头文件，另外这个重定义的宏对他来说一点用也没有。当时我怎么也没想不明白，既然没有包含进那个出错的头文件，怎么会是因为加了这一堆头文件导致的，就算是有重定义的错误也该发生在这些被包含进来的头文件才对呀。原来这些被包含的头文件往往又会包含其它头文件，这样扩展开来是类似树状的结构，一种情况是那个出错的文件被这些头文件直接或间接地包含进来了一次，但是还有其他被比较或间接包含进来的进来的头文件也同时定义了这个宏，只是那个出错的文件被包含的顺序比较靠后一点，所以出错并提示该头文件的那个宏重定义；另一种情况是这个这个出错的头文件被间接地包含了多次，并且这个头文件没有用RULE1去做，当然这种可能性很小。解决该问题的方法是找到去找到被他包含进来的（包括间接包含进来的）的头文件哪里定义了这个宏，却没有用RULE2去定义的。但是这样找很多文件，即使使用Source Insight搜索到所有的包含该宏定义的头文件，也要去确认那些头文件是否属于被他包含的头文件之列，比较麻烦。如果使用#error通过二分法查找，需要不停地编译数次可以找到。另一种方法是在他的某处合适的头文件包含语句之间添加#undef那个宏的语句，可以解决掉这个问题（别人忽然看到可能会觉得奇怪，如果找到精确位置还是要一定功夫的，如果每个包含头文件语句之间都添加这样的语句，会显得很冗赘）。还有专门的工具可以生成文件包含关系，如果手头有这样的工具的话，找起来还是很方便的。RULE3比较容易理解：如果没有遵循RULE3的头文件被多个源文件包含的时候，链接的时候编译器就会发现不知道该使用哪个符号了。总结：RULE1 是作为预防头文件被重复的做法，虽然能够保证头文件不被重复包含，但是却不能预防宏的重定义。在多文件工程的头文件中，应该按此法去做。RULE2可以有效防止宏的重定义，但是某些检查较松的编译器如VC的CL是允许宏重定义的。RULE2可能会让你使用的宏的实际定义变得模糊，有的时候你可能只想使用自己定义的宏，但是你包含的其他头文件可能会已经包含了这个宏名，可以先undef掉。另外，我们应该尽量避免在不同头文件定义同名的宏，而比较公用的、可能会被多个其他文件包含的头文件应该使用RULE2去定义宏，以防止重定义。RULE3是必须遵循的。 二.假定有以下几个头文件及其包含关系为：File1.h，file2.h，file3.h，file4.h，file5.h，main.cpp那么：file3.h包含file1.h，file2.h，file4.h包含file1.h，file2.h，file5.h包含file3.h，file4.h。如许就会导致在file5中对file1和file2的反复包含，编译时就会报错。解决方法：1：应用#ifndef#define#endif即每个文件在定义时都写成以下情势（以file1.h为例）：#ifndef H_FILE1#define H_FILE1#include #include .#endifFile3.h: #ifndef H_FILE3#define H_FILE3#include #include #inlcude