条款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>少两个字,这也是很多人用它的原因。:)

相关文章推荐

条款2 尽量用const,enum,inline代替#define

这个条款改为“尽量把工作交给编译器而不是预编译器”更恰当,因为或许#define不被视为语言的一部分,这正是问题所在,如下: #define  DATA  1.6 编译器也许根本就接触不到这个DA...

条款2:尽量以const,enum,inline 替换 #define

条款2:尽量以const,enum,inline 替换 #define

条款2:尽量以const,enum,inline替换#define

这一条款也被称作:宁可用编译器替换预处理器。从以下几方面说明:(最开始的那一段似乎跟编译原理有关,我是不懂的,就不说了): 对于一般用#defined定义的常量,可以使用const类型代替。 ...

Effective C++ 读书笔记——条款2:尽量以const,enum,inline替换#define

中“宁可以编译器替换预处理”算是另一种提法,不过这个应该是概括性的说法吧 主要事项注意如下: 1用const double AspectRatio=1.653;代替#define ASPECT_R...

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

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

有效的使用和设计COM智能指针——条款10:尽量减少智能指针和接口指针的混用

条款10:尽量减少智能指针和接口指针的混用 更多条款请前往原文出处:http://blog.csdn.net/liuchang5 在开始一节之前,让我们先来看一个例子: void func(...

【让你的C++程序更加高效】条款01:尽量使用常量/内联而不是预处理器/宏定义

C++程序员分为两种,一种读过《让你的C++程序更加高效》,另一种则没有 Item  1:  Prefer const  and inline to #define. OR "prefer...

Effective C++ 阅读笔记_条款27 尽量少做转型动作

Effective C++ 阅读笔记_条款27 尽量少做转型动作 Effective C++ 阅读笔记_条款27 尽量少做转型动作 1.转型的三种形式,可以分为两大类。 (1)旧式转型(...

条款02:尽量以const、enum、inline替换#define

少用#define!!

【让你的C++程序更加高效】条款03:尽量使用new/delete而不是malloc/free

首先说明一下 new/delete是C++的运算符(比如+,-,*,/等都是运算符) malloc/free是函数,在堆(heap)上分配内存/回收内存 假设现在要为一个(或一组)对象分...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:条款2:尽量用而不用
举报原因:
原因补充:

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