http://hi.baidu.com/laddie10/item/3f1e2fd404bd19e6b2f777eb
C++中新定义的方法都是有名字空间的 比如cout就属于std名字空间 如果include头文件的时候加上.h,默认会using namespace 否则需要自己加上 using namespace XXX 对于C中已经定义的方法如printf,没有影响的
iostream.h是包含输入/输出流处理的头文件,iostream就什么都不是了
但用iostream要加名词空间namespace
#include<iostream.h>
或者是
#include<iostream>
using namespace std;
二者都行
#include<iostream.h>是C语言中比较通用的
#include<iostream>
using namespace std;
是C++中比较通用的
#include <iostream.h>这样写,里面的函数都是全局函数.
不加.h的是现在C++中规定的标准,目的在于使C++代码用于移植和混合嵌入时不受扩展名.h的限制,避免因为.h而造成的额外的处理和修改
而加.h的是c语言的用法,但是在c++中也支持这种用法,主要是为了向下兼容c 的内容,我们平时尽量不用这种方法
iostream是现在C++中规定的标准,目的在于使C++代码用于移植和混合嵌入时不受扩展名.h的限制,避免因为.h而造成的额外的处理和修改。iostream包含的基本功能和对应的旧头文件相同,但头文件的内容在名字空间std中。(在标准化的过程中,库中有些部分的细节被修改了,所以旧头文件和新头文件中的实体不一定完全对应。) 一般情况下应该用这个头文件,而iostream.h则是老式的,以后有可能被淘汰。
经常在CSDN以及其他之类的技术论坛上问关于C++ 头文件的问题。提出这些问题的往往就是那些刚学C++的新手。当初我是菜鸟的时候也问过类似的问题。
现在来看看下面两个include:
#include<iostream> // 这个就是1998年标准化以后的标准头文件
#include<iostream.h> // 这个就是标准化以前的头文件
更本质上的区别就是iostream把标准C++库的组件放在一个名位std的namespace里面。而相对的iostream.h则将这些标准组件放在全局空间里,同时在标准化以后旧有的C标准库也已经经过改造了。 使用前者,就需要在代码中添加语句:using namespace std;
看看下面这两个头文件
// 标准化后经过改造的C的标准库,所有的组件都放在了std中
#include<cstdio>
// 标准化以前C++中的C标准库
#include<stdio.h>
// 在看看这个头文件C标准库下 基于char* 的字符处理函数库
#include<string.h>
// 在标准化以后他变成了这样
#include<cstring>
// 但是很多朋友还看见过这个字符串处理函数库,他包含了新的string class
#include<string>
经过了标准委员会如此大规模手术后,在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++标准程序库》。
---------------------------------------------------------------
因为标准库非常的庞大,所程序员在选择的类的名称或函数名时就很有可能和标准库中的某个名字相同。所以为了避免这种情况所造成的名字冲突,就把标准库中的一切都被放在名字空间std中。但这又会带来了一个新问题。无数原有的C++代码都依赖于使用了多年的伪标准库中的功能,他们都是在全局空间下的。
---------------------------------------------------------------
namespace是为了解决C++中的名字冲突而引入的。
什么是名字冲突呢?比如,在文件x.h中有个类MyClass,
在文件y.h中也有个类MyClass,而在文件z.cpp中要同时
引用x.h和y.h文件。显然,按通常的方法是行不能的,
那怎么办呢?引入namespace即可。例如:
// x.h
namespace MyNamespace1
{
};
// y.h
namespace MyNamespace2
{
};
// z.cpp
#include"x.h"
#include"y.h"
void z::f()
{
}
---------------------------------------------------------------
今天突然看到一个这样的说法:很多时候使用这句代码不是一个好的办法:
using namespace std;
更加合适的做法是使用诸如:
std::cout以及std::cin。
我想问下为什么呢?是因为性能的原因吗?
std::cout以及std::cin。是使用系统定义的cout和cin方法且仅使用这两个方法,using namespace std则是将所有的系统定义的标识符导入,也就是说你自己定义的东西(变量,方法,类等)不能和系统中的这些标识符重名,否则将出现命名冲突的错误!
所谓namespace,是指标识符的各种可见范围。
C++标准程序库中的所有标识符都被定义于一个名为std的namespace中。
由于namespace的概念,使用C++标准程序库的任何标识符时,可以有三种选择:
1、直接指定标识符。例如std::ostream而不是ostream。完整语句如下:
2、使用using关键字。
以上程序可以写成
3、最方便的就是使用using namespace std;
例如:
这样命名空间std内定义的所有标识符都有效(曝光)。就好像它们被声明为全局变量一样。那么以上语句可以如下写:
因为标准库非常的庞大,所程序员在选择的类的名称或函数名时就很有可能和标准库中的某个名字相同。所以为了避免这种情况所造成的名字冲突,就把标准 库中的一切都被放在名字空间std中。但这又会带来了一个新问题。无数原有的C++代码都依赖于使用了多年的伪标准库中的功能,他们都是在全局空间下的。
using std::cin;
using std::cout;
using std::endl;
template < typename T >
T max (T a,T b)
{
return ((a>b)?a:b);
}
int main()
{
double x,y;
cin>>x>>y;
cout<<"Max number is "<<(max(x,y))<<endl;
cin>>x;
}
这是我比较推荐的做法,因为C++ PRIMER, EFFECTIVE C++上都是用这种方式的,但是谭浩强的书上都是一句using namespace std;就搞定,我觉得蛮简洁的就一直用了,没想到带来那么多的问题,以前在友元函数上还碰到莫名的错误呢。
其实还有两个简单的解决方案,那就是把自己定义的函数改成其他的名字,或者直接用微软提供的函数。相信微软提供的效率绝对不会比我们写的低~
好了,就写到这了。希望大家养成良好的编程习惯,^-^
---------------------------------------------------------------