条款2:尽量用而不用

转载 2006年05月29日 21:33:00

条款2:尽量用<iostream>而不用<stdio.h>

 

是的,scanf和printf很轻巧,很高效,你也早就知道怎么用它们,这我承认。但尽管他们很有用,事实上scanf和printf及其系列还可以做些改进。尤其是,他们不是类型安全的,而且没有扩展性。因为类型安全和扩展性是C++的基石,所以你也要服从这一点。另外,scanf/printf系列函数把要读写的变量和控制读写格式的信息分开来,就象古老的FORTRAN那样。是该向五十年代说诀别的时候了!

不必惊奇,scanf/printf的这些弱点正是操作符>>和<<的强项:

 

int i;
Rational r;// r 是个有理数

...

cin >> i >> r;
cout << i << r;

上面的代码要通过编译,>>和<<必须是可以处理Rational类型对象的重载函数(可能要通过隐式类型转换)。如果没有实现这样的函数,就会出错(处理int不用这样做,因为它是标准用法)。另外,编译器自己可以根据不同的变量类型选择操作符的不同形式,所以不必劳你去指定第一个要读写的对象是int而第二个是Rational。

另外,在传递读和写的对象时采用的语法形式相同,所以不必象scanf那样死记一些规定,比如如果没有得到指针,必须加上地址符,而如果已经得到了指针,又要确定不要加上地址符。这些完全可以交给C++编译器去做。编译器没别的什么事好做的,而你却不一样。最后要注意的是,象int这样的固定类型和象Rational这样的自定义类型在读写时方式是一样的。而你用sacnf和printf试试看!

你所写的表示有理数的类的代码可能象下面这样:

 

class Rational {
public:
	Rational(int numerator = 0, int denominator = 1);
	
	...
	
private:
	int n, d;// 分子,分母

 

friend ostream& operator<<(ostream& s, const Rational& ); }; ostream& operator<<(ostream& s, const Rational& r) { s<< r.n << '/' << r.d; return s; }

上面的代码涉及到operator<<的一些微妙(但很重要)的用法,这在本书其他地方详细讨论。例如:上面的operator<<不是成员函数(条款19解释了为什么),而且,传递给operator<<的不是Rational对象,而是定义为const的对象的引用(参见条款22)。operator>>的声明和实现也类似。

尽管我不大愿意承认,可有些情况下回到那些经过证明而且正确的老路上去还是很有意义的。第一,有些iostream的操作实现起来比相应的C stream效率要低,所以不同的选择会给你的程序有可能(虽然不一定,参见条款M16)带来很大的不同。但请牢记,这不是对所有的iostream而言,只是一些特殊的实现;参见条款M23。第二,在标准化的过程中,iostream库在底层做了很多修改(参见条款49),所以对那些要求最大可移植性的应用程序来说,会发现不同的厂商遵循标准的程度也不同。第三,iostream库的类有构造函数而<stdio.h>里的函数没有,在某些涉及到静态对象初始化顺序的时候,如果可以确认不会带来隐患,用标准C库会更简单实用。

iostream库的类和函数所提供的类型安全和可扩展性的价值远远超过你当初的想象,所以不要仅仅因为你用惯了<stdio.h>而舍弃它。毕竟,转换到iostream后,你也不会忘掉<stdio.h>。

顺便说一句,本条款的标题没有打印错;我确实说的是<iostream>而非<iostream.h>。从技术上说,其实没有<iostream.h>这样的东西——标准化委员会在简化非C标准头文件时用<iostream>取代了它。他们这样做的原因在条款49进行了解释。还必须知道的是,如果编译器同时支持 <iostream>和<iostream.h>,那头文件名的使用会很微妙。例如,如果使用了#include <iostream>, 得到的是置于名字空间std(见条款28)下的iostream库的元素;如果使用#include <iostream.h>,得到的是置于全局空间的同样的元素。在全局空间获取元素会导致名字冲突,而设计名字空间的初衷正是用来避免这种名字冲突的发生。还有,打字时<iostream>比<iostream.h>少两个字,这也是很多人用它的原因。:)

Effective C++:条款1:尽量用const和inline而不用#define

这个条款最好称为:“尽量用编译器而不用预处理”,因为#define经常被认为好象不是语言本身的一部分。这是问题之一。再看下面的语句: #define ASPECT_RATIO 1.653 编译器会...
  • wangqiulin123456
  • wangqiulin123456
  • 2012年12月01日 22:30
  • 1416

从C转向C++:条款2:尽量用而不用

是的,scanf和printf很轻巧,很高效,你也早就知道怎么用它们,这我承认。但尽管他们很有用,事实上scanf和printf及其系列还可以做些改进。尤其是,他们不是类型安全的,而且没有扩展性。因为...
  • eclipser1987
  • eclipser1987
  • 2010年09月12日 13:53
  • 365

Effective C++:条款2:尽量用<iostream>而不用<stdio.h>

是的,scanf和printf很轻巧,很高效,你也早就知道怎么用它们,这我承认。但尽管他们很有用,事实上scanf和printf及其系列还可以做些改进。尤其是,他们不是类型安全的,而且没有扩展性。因为...
  • wangqiulin123456
  • wangqiulin123456
  • 2012年12月01日 22:43
  • 1033

Effective C++ 条款2:尽量用iostream而不用stdio.h

条款2:尽量用而不用是的,scanf和printf很轻巧,很高效,你也早就知道怎么用它们,这我承认。但尽管他们很有用,事实上scanf和printf及其系列还可以做些改进。尤其是,他们不是类型安全的,...
  • ipromiseu
  • ipromiseu
  • 2009年05月08日 22:20
  • 674

条款2:尽量用<iostream>而不用<stdio.h>

scanf和printf不是类型安全的,而且没有扩展性,而类型安全和扩展性正是C++的基石,scanf/printf的这些弱点正是操作符>>和  int i; Rational r;     // ...
  • yuanzhangmei1
  • yuanzhangmei1
  • 2012年08月20日 08:40
  • 399

条款2:尽量用iostream而不用stdio.h

一 Shifting from c to c++条款2:尽量用而不用scanf和printf及其系列的缺点:(1)他们不是类型安全的(2)没有扩展性(3)scanf/printf系列函数把要读写的变量...
  • developinglife
  • developinglife
  • 2011年06月30日 11:42
  • 428

尽量用“传引用”而不用“传值”--------(读后感)

 /*注:转载请保留下面完整信息From   http://blog.csdn.net/missvip/    By 凌剑*/为什么EffectiveC++提出尽量用“传引用”而不用“传值”了?今天...
  • missvip
  • missvip
  • 2007年09月12日 22:40
  • 442

effective c++ 条款22: 尽量用“传引用”而不用“传值”

条款20: 避免public接口出现数据成员 条款20: 避免public接口出现数据成员首先,从“一致性”的角度来看这个问题。如果public接口里都是函数,用户每次访问类的成员时就用不着抓脑...
  • fengxinziyang
  • fengxinziyang
  • 2010年09月15日 09:40
  • 321

条款1:尽量用const和inline而不用#define

这个条款最好称为:“尽量用编译器而不用预处理”,因为#define经常被认为好象不是语言本身的一部分。这是问题之一。再看下面的语句: #define ASPECT_RATIO 1.653 编译器会...
  • imsaws
  • imsaws
  • 2014年02月21日 13:06
  • 391

条款 22: 尽量用“传引用”而不用“传值”

除非明确指定,函数的形参总是通过“实参的拷贝”来初始化的,函数的调用者得到的也是函数返回值的拷贝。用传值来传递对象,会调用大量的构造函数和析构函数,效率低下。所以,为避免这种潜在的昂贵的开销,就不要通...
  • lujiandong1
  • lujiandong1
  • 2014年12月27日 20:00
  • 314
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:条款2:尽量用而不用
举报原因:
原因补充:

(最多只允许输入30个字)