#include<iostream>与#include<iostream.h>的区别

                                    

转载于祝长洋的BLOG:http://blog.sina.com.cn/s/blog_514b5f600100ayks.html

                                    

这两者都有什么不同呢?首先,5年前我们就开始反对把.h符号继续用在标准的头文件中。继续使用过时的规则可不是个好的方法。从功能性的角度来讲,包含了一系列模板化的I/O

类,相反地只仅仅是支持字符流。另外,输入输出流的C++标准规范接口在一些微妙的细节上都已改进,因此,和在接口和执行上都是不同的。最后,的各组成都是以STL(Standard
Template

Library,标准模板库)的形式声明的,然而的各组成都是声明成全局型的。

因为这些实质上的不同,你不能在一个程序中混淆使用这两个库。做为一种习惯,在新的代码中一般使用,但如果你处理的是过去编写的代码,为了继承可以用继续用就保持代码的

一致性。

/////////////////////////////

表示你使用的是标注命名空间,也就是在程序开始应该有这么一句话

using namespace std ;
这是遵循c++标准的

则没有遵循c++标准

/////////////////////////////

是旧的C头文件,对应的是基于char*的字符串处理函数;

是包装了std的C++头文件,对应的是新的strng类;

是对应旧的C头文件的std版本。

#include 和 #include

前一个不是c++标准中的,后一个在c++标准中

还有就是平时我们所用的两种情况,当有输出和输入流时就要注意了。

换成#include ,要加一句using namespace
std;或把cout改成std::cout,end改成std::endl等等

/////////////////////////////////////////////////////////////////////////////

这个问题牵扯到命名空间,以下简单介绍命名空间的优点:

// one.h char func(char); class
String { ... };

// somelib.h class String { ...
};

如果按照上述方式定义,那么这两个头文件不可能包含在同一个程序中,因为String类会发生冲突。所谓命名空间,是一种将程序库名称封装起来的方法,它就像在各个程序库中立起一道道

围墙。

比如:

// one.h namespace one { char
func(char); class String { ... }; }

// somelib.h namespace SomeLib {
class String { ... }; }

std是C++标准库定义的标准命名空间,可以先记住这两种方式,时间长了就明白了

//////////////////////////////////////////////////////////////////////////////

对于这个问题,某个马嘉楠老师如是说:

其实没有< iostream.h
> 这样的东西 --- 标准化委员会在简化非C标准头文件时用< iostream > 取代了它。但又没有完全取消 <
iostream.h > 的使用,并且很多编译器都同时支持

<iostream
> 和< iostream.h > ,造成现在的局面,老大(标准化委员会)确实有不得已的苦衷。

话说当年,在标准化委员会动手重建新的标准库的时候,遇到了问题。为了避免类名和函数名的冲突问题,引入了名字空间std。但无数现有的C++代码都依赖于使用了多年的伪标准库中的功

能,例如,声明在< iostream.h > 和<
complex.h >
等头文件中的功能。现有软件没有针对使用名字空间而进行相应的设计或升级,如果用std来包装标准库导致现有代码不能使用,那手底

下的小弟(程序员)是不会同意的。

标准化委员会为了拉拢人心,吸引更多的人入会,决定为包装了std的那部分标准库构建新的头文件名。将现有C++头文件名中的.h去掉,所以就出现了<
iostream.h> 和< iostream > 等很多

双胞胎。对于C头文件,采用同样方法但在每个名字前还要添加一个C,所以C的
变成了。

旧的C++头文件是官方明确反对使用的,但旧的C头文件则没有(以保持对C的兼容性)。其实编译器制造商不会停止对客户现有软件提供支持,所以在可以预计的将来,旧的C++头文件还会嚣

张一段时间。如果能明白字符串头文件的使用,举一反三,其他的也差不多会用了。

是旧的C头文件,对应的是基于char*的字符串处理函数;

是包装了std的C++头文件,对应的是新的strng类;

是对应旧的C头文件的std版本。

跑远了,言归正传。如果你的编译器都同时支持< iostream
> 和< iostream.h >,那使用 #include < iostream
>,得到的是置于名字空间std下的iostream库的元素;如果使用 #include
< iostream.h
>,得到的是置于全局空间的同样的元素。在全局空间获取元素会导致名字冲突,而设计名字空间的初衷正是用来避免这种名字冲突的发生。还有,打字时<
iostream > 比 <iostream.h > 少两个字,所以我会使用< iostream >
^_^

                    

转自:http://hi.baidu.com/laddie10/blog/item/079b1d4c32d7d8fcd62afc25.html

                    

C++中新定义的方法都是有名字空间的 比如cout就属于std名字空间 如果include头文件的时候加上.h,默认会using
namespace 否则需要自己加上 using namespace XXX
对于C中已经定义的

方法如printf,没有影响的iostream.h是包含输入/输出流处理的头文件,iostream就什么都不是了 但用iostream要加名词空间namespace

#include

或者是

#include

using namespace
std;

二者都行

#include是C语言中比较通用的

#include

using namespace
std;

是C++中比较通用的

#include
这样写,里面的函数都是全局函数.

不加.h的是现在C++中规定的标准,目的在于使C++代码用于移植和混合嵌入时不受扩展名.h的限制,避免因为.h而造成的额外的处理和修改

而加.h的是c语言的用法,但是在c++中也支持这种用法,主要是为了向下兼容c
的内容,我们平时尽量不用这种方法

iostream是现在C++中规定的标准,目的在于使C++代码用于移植和混合嵌入时不受扩展名.h的限制,避免因为.h而造成的额外的处理和修改。iostream包含的基本功能和对应的旧头文件相同

,但头文件的内容在名字空间std中。(在标准化的过程中,库中有些部分的细节被修改了,所以旧头文件和新头文件中的实体不一定完全对应。)
一般情况下应该用这个头文件,而iostream.h则是老式的,以后有可能被淘汰。

经常在CSDN以及其他之类的技术论坛上问关于C++
头文件的问题。提出这些问题的往往就是那些刚学C++的新手。当初我是菜鸟的时候也问过类似的问题。

现在来看看下面两个include:

#include  
   // 这个就是1998年标准化以后的标准头文件

#include  
     // 这个就是标准化以前的头文件

更本质上的区别就是iostream把标准C++库的组件放在一个名位std的namespace里面。而相对的iostream.h则将这些标准组件放在全局空间里,同时在标准化以后旧有的C标准库也已经经过改造了。
使用前者,就需要在代码中添加语句:using namespace std;

看看下面这两个头文件

//
标准化后经过改造的C的标准库,所有的组件都放在了std中

#include

//
标准化以前C++中的C标准库

#include

// 在看看这个头文件C标准库下
基于char* 的字符处理函数库

#include

//
在标准化以后他变成了这样

#include

//
但是很多朋友还看见过这个字符串处理函数库,他包含了新的string class

#include

经过了标准委员会如此大规模手术后,在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的头文件如stdio.h继续获得支持,这类文件的内容并未放在std中。

4.
C函数库的技能也有对应的新式C++版本,起名称类似cstdio,这类头文件的内容也有幸穿上了std的外衣。

其实标准化以后的标准程序库的改动并不只有这些而已,很多的标准化组件都被“tamplate化”。其中就有元老级人物iostream。标准程序库的问题并不是用一篇,两篇文章就可以说清楚的

。如果你像进一步的了解C++的标准程序库的话,你可以看看侯先生的《C++标准程序库》。

#include<iostream>与#include<iostream.h>的区别

时间: 2024-10-19 16:37:42

#include<iostream>与#include<iostream.h>的区别的相关文章

C++中#include包含头文件带 .h 和不带 .h 的区别

C++中#include包含头文件带 .h 和不带 .h 的区别? 如 #include <iostream> 和 #include <iostream.h> 包含的东西有哪些不同? 之前在写C++程序的时候只知道使用 #include <iostream> 的时候,使用函数前要用 using namespace std; 导入命名空间,而 #include <iostream.h> 则不用,这个得看C+ +标准化过程为C++开发者做了哪些有意义的工作. (

关于命名空间的理解---iostream与iostream.h的区别

C++中为了避免名字定义冲突,特别引入了"名字空间的定义",即namespace.当代码中用<iostream.h>时,输出可直接引用cout<<x;<iostream.h>继承C语言的标准库文件,未引入名字空间定义,所以可直接使用. 当代码中引入<iostream>时(C++标准),输出需要引用std::cout<<x;如果还是按原来的方法就会有错,或者直接添加using namespace std; 实例: code1 #

头文件---#include&lt;***.h&gt;和#include&quot;***.h&quot;的区别

采用"< >"方式进行包含的头文件表示让编译器在编译器的预设标准路径下去搜索相应的头文件,如果找不到则报错. 例如:VS的安装目录\Microsoft Visual Studio 9.0\VC\include下面就包含了标准库的头文件. 第二种方式表示先在工程所在路径下搜索,如果失败,再到系统标准路径下搜索. 所以,特别要注意的是,如果是标准库头文件,那么既可以采用<>的方式,又可以采用" "的方式,而用户自定义的头文件只能采用"

转载 关于include尖括号和双引号的区别。

对于使用尖括号( < >),预处理程序cpp在系统预设包含文件目录(如/usr/include)中搜寻相应的文件,而对于使用双引号(“ ”),cpp在当前目录中搜寻头文件,这个选项的作用是告诉cpp,如果在当前目录中没有找到需要的文件,就到指定的dirname目录中去寻找.在程序设计中,如果我们需要的这种包含文件分别分布在不同的目录中,就需要逐个使用-I选项给出搜索路径. 通常用 < >包含的是标准库的头文件,而用""包含的是用户自己定义的类库的头文件.&quo

include指令和include动作的区别

include指令和include动作的区别 1.include指令 include可以在JSP页面转换成Servlet之前,将JSP代码插入其中.它的主要优点是功能强大,所包含的代码可以含有总体上影响主页面的JSP构造,比如属性.方法的定义和文档类型的设定.它的缺点是难于维护只要被包含的页面发生更改,就得更改主页面,这是因为主页面不会自动地查看被包含的页面是否发生更改. include指令的语法格式如下: <%@ include file="Relative Url"%>

include与jsp:include区别

我们都知道在jsp中include有两种形式,分别是 <%@ include file=” ”%> <jsp:include page=” ” flush=”true”/> 前者是指令元素.后者是行为元素.具体它们将在何处用?如何用及它们有什么区别?这应该是很多人看到它都会想到的问题 一:执行时间上: <%@ include file=”relativeURI”%> 是在翻译阶段执行 <jsp:include page=”relativeURI” flush=”t

JSP中include指令和include动作区别

首先 <%@ include file=" "%>:为指令元素 <jsp:include page=" " flush="true"/>:为 动作元素 先说指令元素: include指令元素读入指定页面的内容.并把这些内容和原来的页面融合到一起. 然后经过两个阶段: 1.将jsp翻译成 servlet  2.servlet 翻译成 .class文件 这样的话,在被引入文件中请不要加入 contentype 的属性 ,因为j

JSP 中动态 INCLUDE 与静态 INCLUDE 的区别?

一.静态包含指令<%@include file=“fileurl”%> 两个jsp页面的<%@page contentType=“text/html:charset=gbk”%>应该保持一致 不能通过fileurl向被包含的jsp页面传递参数,因为此静态包含是发生在jsp页面转换为servlet的转换期间,此时的参数是服务器端设置的死的参数,完全没有经过客户端,这种参数是没有意义的,如<%@include file=“fileurl?user=admin”%>,而且此时

&lt;jsp:include page=&quot;&quot;&gt;和&lt;%@ include file=&quot;&quot;%&gt;区别总结

<jsp:include page="">和<%@ include file=""%>区别总结 1:<jsp:include page="top.jsp">:先将top.jsp中的java脚本和jsp指令都执行完毕以后再将top.jsp页面加入到引用页面中. 2:<%@ include file="top.jsp"%>静态读取:则是将top.jsp的整个页面不加解析(无论是脚本还