首页 > 代码库 > include .h 以及.cpp的记录
include .h 以及.cpp的记录
VC include 路径解析
要了解vc中使用#include命令包含头文件所搜寻的路径,必须先了解vc中的几种路径:
1. 系统路径
系统路径在vc中是"Tools->Options->Directories"中"Include files"指定的路径。
打开此对话框会发现默认有这几条路径:
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE
C:\Program Files\Microsoft Visual Studio\VC98\MFC\INCLUDE
C:\Program Files\Microsoft Visual Studio\VC98\ATL\INCLUDE
我们可以在这里添加,这样我们自己添加的路径也会成为系统路径。添加的格式必须按照上面来写。
2. 当前路径
当前路径是指.cpp文件所在路径,而不是网上有网友说的vc的工程文件(vc6.0为.dsw; vc2008为.vcproj)
3. 附加路径
附加路径是指在"Project->Settings->C/C++->Preprocessor->Additional include directories "中指定的路径。在vc2008中,指的是在工程属性中的包含的路径。
此路径默认为空,我们可以在此处填写需要路径,比如:在此处填入"C:\123\",(不要引号),那么附加路径就会变成"C:\123\" 。这里也可以根据“编辑”选项里面的宏定义进行替换。
上面的1,3路径,我们均可以自己编辑。在编辑过程中,可以使用绝对路径,也可以使用相对路径。
比如,在添加系统路径时,可以这样填写:(.\表示当前路径;..\表示上一层目录)
.\SRC\ 这样写表示,当前目录中的SRC文件夹;
..\SRC\ 这样写表示,当前目录的上一层目录中SRC文件夹;
...\SRC\ 这样写表示,当前目录下 ..\SRC\\ 路径,当然这种写法已经和第一种重叠了。
这种相对路径的写法,vc会自动帮我们转化为绝对路径。
在添加附加路径时,其相对路径的写法和系统路径是一致的。
在vc中使用#include 命令,有三种形式:
1. #include <file.h>
vc执行这条指令时,它会在系统目录中去查找 file.h 文件。在此条码命令中,vc不会去当前路径和附加路径中查找文件。
2. #include "file.h"
vc执行这条指令时,依次搜索第一,第二,第三,找到了就不继续往下搜索。
第一,搜索用到该头文件(#include "file.h")的.cpp文件所在路径,即当前路径;(以.cpp文件为参考点进行搜索)
第二,搜索附加路径+include好面括号里面的文件。例如,附加路径为:"D:\test", 则,第二步就搜索
"D:\test\file.h";(在生成的绝对路径中搜索.h文件)
第三,搜索系统路径;(在系统路径下搜索.h文件)
3. #include "directory\file.h"
vc执行这条指令时,依次搜索第一,第二,第三,找到了就不继续往下搜索。
第一,搜索当前路径(用到该头文件(#include "file.h")的.cpp文件所在路径)是否有一个directory文件夹,如果有,则搜索该文件夹子下是否有file.h文件。
第二,搜索附加路径+include好面括号里面的文件。例如,附加路径为:"D:\test", 则,第二步就搜索
"D:\test\directory\file.h";
第三,搜索系统路径。
总结:VC中的include的路径问题困扰了我很长一段时间,经过写测试实例验证后,发现了如上的规律。其中,把握include的路径问题,主要是要把握相对的文件是哪个,例如,当前路径,指的就是“用到头文件的cpp文件的路径”;而附加路径,则一定要和include里面的文件相结合,形成一个绝对路径。非常需要注意的一点就是,include的路径问题,与工程文件(.dsw和.vcproj)一点关系都没有。
头文件如何来关联源文件?<!--[endif]--> 这个问题实际上是说,已知头文件“a.h”声明了一系列函数,“b.cpp”中实现了这些函数,那么如果我想在“c.cpp”中使用“a.h”中声明的这些在“b.cpp”中实现的函数,通常都是在“c.cpp”中使用#include “a.h”,那么c.cpp是怎样找到b.cpp中的实现呢?
其实.cpp和.h文件名称没有任何直接关系,很多编译器都可以接受其他扩展名。比如偶现在看到偶们公司的源代码,.cpp文件由.cc文件替代了。 在Turbo C中,采用命令行方式进行编译,命令行参数为文件的名称,默认的是.cpp和.h,但是也可以自定义为.xxx等等。 谭浩强老师的《C程序设计》一书中提到,编译器预处理时,要对#include命令进行“文件包含处理”:将file2.c的全部内容复制到#include “file2.c”处。这也正说明了,为什么很多编译器并不care到底这个文件的后缀名是什么----因为#include预处理就是完成了一个“复制并插入代码”的工作。 编译的时候,并不会去找b.cpp文件中的函数实现,只有在link的时候才进行这个工作。我们在b.cpp或c.cpp中用#include “a.h”实际上是引入相关声明,使得编译可以通过,程序并不关心实现是在哪里,是怎么实现的。源文件编译后成生了目标文件(.o或.obj文件),目标文件中,这些函数和变量就视作一个个符号。在link的时候,需要在makefile里面说明需要连接哪个.o或.obj文件(在这里是b.cpp生成的.o或.obj文件),此时,连接器会去这个.o或.obj文件中找在b.cpp中实现的函数,再把他们build到makefile中指定的那个可以执行文件中。 在Unix下,甚至可以不在源文件中包括头文件,只需要在makefile中指名即可(不过这样大大降低了程序可读性,是个不好的习惯哦^_^)。在VC中,一帮情况下不需要自己写makefile,只需要将需要的文件都包括在project中,VC会自动帮你把makefile写好。 通常,编译器会在每个.o或.obj文件中都去找一下所需要的符号,而不是只在某个文件中找或者说找到一个就不找了。因此,如果在几个不同文件中实现了同一个函数,或者定义了同一个全局变量,链接的时候就会提示“redefined”。