t;<(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