在编译工程的时候,遇到了一些恶心的问题:
A.h
#ifndef A_H
#define A_H
class A
{
public:
struct B
{};
};
#endif
在B.h里面进行这样的调用
B.h
#ifndef B_H
#define B_H
#include "A.h"
class BB
{
private:
A::B* ab;
};
#endif
这里出现B.h里面不能找到A的问题了,我一直在想,如果将头文件包含进去了,那么编译器应该就要知道了吧,但是事实上都没有按照那样的做法去完成.
后来查找了一下,是因为出现了调用环. A.H调用了B.H,而B.h由调用了C.h,而C.h又调用了A.h就这样形成了调用环的关系,结果A.h里面的东西就出现了问题,连简单的类都不能被识别了,这样的问题出现是由于滥用包含头文件的原因,在头文件里面尽量要少包含东西,多前置声明,只将信息暴露给实现文件,让实现文件知道多一点,而让头文件暴露得信息少一点.
另外还值得说明的几点是:1)尽量多使用防止重复包含的做法,比如使用
#ifndef XXX_H
#define XXX_H
#endif
这样的话,就不会造成包含次数过多的情况.
2)保证防止重复包含的条件编译标志唯一性,因为按照其说明的要求,一旦声明了某个标志,那么就不会再编译了那个头文件,如果 存在相同的文件编译标志,那么就说明某个文件一定是漏过编译了.这样显然会出错的,之前遇到一个类似上面的问题,包含进去头文件了,却找不到头文件里面对应的声明,后来找了一下,才发现这个文件的条件编译标志跟另外一个文件的条件编译标志是一样的,因而跳过了编译当前文件.
头文件一定要把握好了，突然想起来一个建议:在写好代码以后,可以用doxygen来察看工程里面的文件组织格式和类结构格式,这样如果存在不妥的话,一定得要重新设计和规划了,呵呵,不写了,回家了.