C与C中头文件的引用细节.docxVIP

1、 HYPERLINK /kobesdu/article/detailsC++包含头文件中和的区别 #include “book.h” #includeiostream.h includeXX.h表示在标准库里面找(不用加绝对路径)include..\XX.h表示在指定文件中找(需要加路径(绝对或相对都行),本例是只在本级目录的上一级查找XX.h) 和表示编译器在搜索头文件时的顺序不同，表示从系统目录下开始搜索，然后再搜索PATH环境变量所列出的目录，不搜索当前目录，是表示从当前目录开始搜索，然后是系统目录和PATH环境变量所列出的目录。 所以，系统头文件一般用，用户自己定义的则可以使用，加快搜索速度 2、 HYPERLINK /u012150179/article/details带.h和不带.h的头文件的区别 #include iostream.h#include fstream.husing namespace std; 在以上边的方式定义了头文件后,如果在程序中创建如: ofstream file 对象的时候编译是会产生如下错误: ofstream:ambiguous symbol 这是二义性错误 以下是正确用法和区别: 现在来看看下面两个include:? ???? #includeiostream????? // 这个就是1998年标准化以后的标准头文件 ???? #includeiostream.h??????? // 这个就是标准化以前的头文件 ???? 更本质上的区别就是iostream把标准C++库的组件放在一个名位std的namespace里面。而相对的iostream.h则将这些标准组件放在全局空间里，同时在标准化以后旧有的C标准库也已经经过改造了。 使用前者，就需要在代码中添加语句：using namespace std; ????? 看看下面这两个头文件 ????? // 标准化后经过改造的C的标准库，所有的组件都放在了std中 ????? #includecstdio??????????? ????? // 标准化以前C++中的C标准库 ????? #includestdio.h ????? // 在看看这个头文件C标准库下 基于char* 的字符处理函数库 ????? #includestring.h ????? // 在标准化以后他变成了这样 ????? #includecstring ????? // 但是很多朋友还看见过这个字符串处理函数库，他包含了新的string class ????? #includestring ???? 经过了标准委员会如此大规模手术后，在98年以前出品的C++编译器（BC3.0，BC5.0）上能顺利通过编译的源文件，在支持新标准的编译器上可能无法顺利通过编译也就是很正常的事了。 ?[起因? ?在回过头来看看标准程序库，这个程序库涵盖范围相当广大，提过了许许多多好用的功能。正是因为这样标准程序库中class的名称和函数名与第三方提供的程序库中的class名或是函数名发生名字冲突的可能性大大增大。为了避免这个问题的发生，标准委员会决定将标准程序库中每一样东西都放在namespace std中。但是这么做同时有引来了一个新的问题。很多C++程序代码依赖那些已经存在很多年的C++ “准”标准程序库（C++迟迟未标准化才导致这些情况的发生），例如iosteam.h,complex.h等等。 ?为了解决这个新出现的问题，标准化委员会决定设计一些新的头文件名，给那些穿上std外衣的组件所使用。把C++头文件的.h去掉，于是就有前面出现的iostream，同样C的头文件也做了相同的处理，同时在前面加上了一个字母c，以表示是C的头文件（感觉上有中种族歧视的感觉）。同时标准化委员会声明就有的C++头文件将不再列于被支持的名单之中了，而旧有的C头文件为了满足“对C的兼容性”这个古老契约，仍然将继续存活下去。 ?但是，那些编译器厂商不可能去推翻他们客户的旧有编译器（也跟本不会去这么做），所以那些旧有的C++头文件仍然苟延残喘的活了下来，并不断的扰乱那些C++新兵的心智。 ??下面就是现在大多数C++开发工具表示头文件的组织状态： ?1.???? 旧的C++头文件 比如iostream.h，他们虽然被标准化委员会所抛弃，但由于各大厂商为了各自的商业利益仍然将继续存活下去，这些头文件的内容将不处于namespace std中。 ?2.???? 新的C++头文件如iostream虽然提供了和旧有头文件相同的功能，但他的内容都并入了namespace std中，从而有效避免了名字污染的问题。 ?3.???? 标准C的头文件如stdi