除非你正在用老的编译器(即写于1995年之前)，你不必借用enum。当然，知道有这种方法还是值得的，因为这种可以追溯到很久以前的时代的代码可是不常见的哟。

　　回到预处理的话题上来。另一个普遍的#define指令的用法是用它来实现那些看起来象函数而又不会导致函数调用的宏。典型的例子是计算两个对象的大值：


#define max(a，b) ((a) > (b) ? (a) : (b))


　　这个语句有很多缺陷，光想想都让人头疼，甚至比在高峰时间到高速公路去开车还让人痛苦。

　　无论什么时候你写了象这样的宏，你必须记住在写宏体时对每个参数都要加上括号；否则，别人调用你的宏时如果用了表达式会造成很大的麻烦。但是即使你象这样做了，还会有象下面这样奇怪的事发生：


int a = 5， b = 0;
max(++a， b);// a 的值增加了2次
max(++a， b+10); // a 的值只增加了1次


　　这种情况下，max内部发生些什么取决于它比较的是什么值！

　　幸运的是你不必再忍受这样愚笨的语句了。你可以用普通函数实现宏的效率，再加上可预计的行为和类型安全，这是内联函数（见条款33）：


inline int max(int a， int b) { return a > b ? a : b; }


　　不过这和上面的宏不大一样，因为这个版本的max只能处理int类型。但模板可以很轻巧地解决这个问题：


template<class T>
inline const T& max(const T& a， const T& b)
{ return a > b ? a : b; }


　　这个模板产生了一整套函数，每个函数拿两个可以转换成同种类型的对象进行比较然后返回较大的（常量）对象的引用。因为不知道T的类型，返回时传递引用可以提高效率（见条款22）。

　　顺便说一句，在你打算用模板写象max这样有用的通用函数时，先检查一下标准库（见条款49），看看他们是不是已经存在。比如说上面说的max，你会惊喜地发现你可以后人乘凉：max是C++标准库的一部分。

　　有了const和inline，你对预处理的需要减少了，但也不能完全没有它。抛弃#include的日子还很远，#ifdef/#ifndef在控制编译的过程中还扮演重要角色。预处理还不能退休，但你一定要计划给它经常放长假。

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