本站动态：
上一篇
下一篇
头文件的部分规则：重定义相关
作者:shosh 日期:2010-01-28
Author: Shosh
Site: http://www.wscxy.com
RULE1: 每个头文件都用以下宏包起来，防止被其他文件多次包含。
#ifndef __FILENAME_H__
#define __FILENAME_H__
（……文件内容……）
#endif //__FILENAME_H__
RULE2: 在定义一个宏的时候，考虑是否需要检测是否已经被定义过。
#ifndef MACRO_NAME
#define MACRO_NAME MACRO_VALUE
#endif
RULE3：头文件中不要去定义全局变量，也就是说头文件中的所有语句不能涉及实际内存的分配。
对于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是必须遵循的。
Site: http://www.wscxy.com
RULE1: 每个头文件都用以下宏包起来，防止被其他文件多次包含。
#ifndef __FILENAME_H__
#define __FILENAME_H__
（……文件内容……）
#endif //__FILENAME_H__
RULE2: 在定义一个宏的时候，考虑是否需要检测是否已经被定义过。
#ifndef MACRO_NAME
#define MACRO_NAME MACRO_VALUE
#endif
RULE3：头文件中不要去定义全局变量，也就是说头文件中的所有语句不能涉及实际内存的分配。
对于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是必须遵循的。
文章来自: 
引用通告: 
Tags: 
相关日志:
评论: 0 | 引用: 0 | 查看次数: 600
发表评论
