📄 8578.htm
字号:
<HTML>
<HEAD>
<meta http-equiv='Content-Type' content='text/html; charset=gb2312'>
<style >
.fst{padding:0px 15px;width:770px;border-left:0px solid #000000;border-right:0px solid #000000}
.fstdiv3 img{border:0px;border-right:8px solid #eeeecc;border-top:6px solid #eeeecc}
</style>
<title>
Effective C++ 2e Item2
</title>
</HEAD>
<BODY >
<center>
<div align=center><div class=fst align=left><div class=fstdiv3 id=print2>
<P><b>
Effective C++ 2e Item2</b></P>
<P>条款2：尽量用<iostream>而不用<stdio.h></P>
<P>是的，scanf和printf很轻巧，很高效，你也早就知道怎么用它们，这我承认。但尽管他们很有用，事实上scanf和printf及其系列还可以做些改进。尤其是，他们不是类型安全的，而且没有扩展性。因为类型安全和扩展性是C++的基石，所以你也要服从这一点。另外，scanf/printf系列函数把要读写的变量和控制读写格式的信息分开来，就象古老的FORTRAN那样。是该向五十年代说诀别的时候了！</P>
<P>不必惊奇，scanf/printf的这些弱点正是操作符>>和<<的强项:<BR> int i;<BR> Rational r; // r 是个有理数</P>
<P> ...</P>
<P> cin >> i >> r;<BR> cout << i << r;</P>
<P>上面的代码要通过编译，>>和<<必须是可以处理Rational类型对象的重载函数(可能要通过隐式类型转换)。如果没有实现这样的函数，就会出错(处理int不用这样做，因为它是标准用法)。另外，编译器自己可以根据不同的变量类型选择操作符的不同形式，所以不必劳你去指定第一个要读写的对象是int而第二个是Rational。</P>
<P>另外，在传递读和写的对象时采用的语法形式相同，所以不必象scanf那样死记一些规定，比如如果没有得到指针，必须加上地址符，而如果已经得到了指针，又要确定不要加上地址符。这些完全可以交给C++编译器去做。编译器没别的什么事好做的，而你却不一样。最后要注意的是，象int这样的固定类型和象Rational这样的自定义类型在读写时方式是一样的。而你用sacnf和printf试试看！</P>
<P>你所写的表示有理数的类的代码可能象下面这样：<BR> class Rational {<BR> public:<BR> Rational(int numerator = 0, int denominator = 1);</P>
<P> ...</P>
<P> private:<BR> int n, d; // 分子，分母</P>
<P> friend ostream& operator<<(ostream& s, const Rational& r);<BR> };</P>
<P> ostream& operator<<(ostream& s, const Rational& r)<BR> {<BR> s << r.n << '/' << r.d;<BR> return s;<BR> }</P>
<P>上面的代码涉及到operator<<的一些微妙(但很重要)的用法，这在本书其他地方详细讨论。例如：上面的operator<<不是成员函数(条款19解释了为什么)，而且，传递给operator<<的不是Rational对象，而是定义为const的对象的引用(参见条款22)。operator>>的声明和实现也类似。</P>
<P>尽管我不大愿意承认，可有些情况下回到那些经过证明而且正确的老路上去还是很有意义的。第一，有些iostream的操作实现起来比相应的C stream效率要低，所以不同的选择会给你的程序有可能(虽然不一定，参见条款M16)带来很大的不同。但请牢记，这不是对所有的iostream而言，只是一些特殊的实现；参见条款M23。第二，在标准化的过程中，iostream库在底层做了很多修改(参见条款49)，所以对那些要求最大可移植性的应用程序来说，会发现不同的厂商遵循标准的程度也不同。第三，iostream库的类有构造函数而<stdio.h>里的函数没有，在某些涉及到静态对象初始化顺序的时候，如果可以确认不会带来隐患，用标准C库会更简单实用。</P>
<P>iostream库的类和函数所提供的类型安全和可扩展性的价值远远超过你当初的想象，所以不要仅仅因为你用惯了<stdio.h>而舍弃它。毕竟，转换到iostream后，你也不会忘掉<stdio.h>。</P>
<P>顺便说一句，本条款的标题没有打印错；我确实说的是<iostream>而非<iostream.h>。从技术上说，其实没有<iostream.h>这样的东西——标准化委员会在简化非C标准头文件时用<iostream>取代了它。他们这样做的原因在条款49进行了解释。还必须知道的是，如果编译器同时支持 <iostream>和<iostream.h>，那头文件名的使用会很微妙。例如，如果使用了#include <iostream>, 得到的是置于名字空间std(见条款28)下的iostream库的元素；如果使用#include <iostream.h>，得到的是置于全局空间的同样的元素。在全局空间获取元素会导致名字冲突，而设计名字空间的初衷正是用来避免这种名字冲突的发生。还有，打字时<iostream>比<iostream.h>少两个字，这也是很多人用它的原因。:)<br>
</P>
</DIV></div></div>
</center></BODY></HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -