EffectiveC读书笔记条款2

　　条款 2：尽量用而不用
　　scanf 和 printf 很轻巧，很高效。尽管他们很有用，但还是可以做些改进的。尤其是，他们不是类型安全的，而且没有扩展性(它们是C++的基石)。
　　scanf/printf 的这些弱点正是操作符>>和<<的强项；     int i;     Rational r;                           // r  是个有理数     cin >> i >> r;      cout << i << r;
　　说明:上面的代码要通过编译，>>和<<必须是可以处理 Rational 类型对象的重载函数(可能要通过隐式类型转换)。如果没有实现这样的函数，就会出错(处理 int 不用这样做，因为它是标准用法)。另外，编译器自己也可以根据不同的变量类型选择操作符的不同形式，所以不必劳你去指定第一个要读写的对象是 int 而第二个是 Rational。
　　有些情况下回到那些经过证明而且正确的老路上去还是很有意义的。
　　第一，有些 iostream 的操作实现起来比相应的C stream 效率要低，所以不同的选择会给你的程序(虽然不一定，参见条款 M16) 带来很大的不同。但请牢记，这不是对所有的iostream ，只是一些特殊的实现；参见条款 M23。
　　第二，在标准化的过程中，iostream 库在底层做了很多修改(参见条款 49)，所以对那些要求最大可移植性的应用程序来说，会发现不同厂商遵循标准的程度也不同。
　　第三，iostream 库的类有构造函数，而里面的函数没有，在某些涉及到静态对象初始化顺序的时候，如果可以确认不会带来隐患，用标准 C 库会更简单实用。
　　顺便说一句，本条款的标题没有打印错。是而非 。从技术上说，其实没有这样的东西——标准化委员会在简化非 C 标准头文件时，用取代了它。他们这样做的原因在条款49 进行了解释。还必须知道的是，如果编译器同时支持 和  ，那头文件名的使用会很微妙。例如，如果使用了#include , 得到的是置于名字空间 std(见条款 28)下的 iostream 库的元素； 如果使用#include ，得到的是置于全局空间的同样的元素。在全局空间获取元素会导致名字冲突，而设计名字空间的初衷正是用来避免名字冲突。还有，打字时比少两个字，这也是多数人它的原因。)