搜索
第一章从C转向C++对每个人来说，习惯C++需要一些时间，对于已经熟悉C的程序员来说，这个过程尤其令人苦恼。因为C是C++的子集，所有的C的技术都可以继续使用，但很多用起来又不太合适。例如，C++程序员会认为指针的指针看起来很古怪，他们会问：为什么不用指针的引用来代替呢？C是一种简单的语言。它真正提供的只有有宏、指针、结构、数组和函数。不管什么问题，C都靠宏、指针、结构、数组和函数来解决。而C++不是这样。宏、指针、结构、数组和函数当然还存在，此外还有私有和保护型成员、函数重载、缺省参数、构造和析构函数、自定义操作符、内联函数、引用、友元、模板、异常、名字空间，等等。用C++比用C具有更宽广的空间，因为设计时有更多的选择可以考虑。在面对这么多的选择时，许多C程序员墨守成规，坚持他们的老习惯。一般来说，这也不是什么很大的罪过。但某些C的习惯有悖于C++的精神本质，他们都在下面的条款进行了阐述。--------------------------------------------------------------------------------条款1：尽量用const和inline而不用#define这个条款最好称为：“尽量用编译器而不用预处理”，因为#define经常被认为好象不是语言本身的一部分。这是问题之一。再看下面的语句：#defineASPECT_RATIO1.653编译器会永远也看不到ASPECT_RATIO这个符号名，因为在源码进入编译器之前，它会被预处理程序去掉，于是ASPECT_RATIO不会加入到符号列表中。如果涉及到这个常量的代码在编译时报错，就会很令人费解，因为报错信息指的是1.653，而不是ASPECT_RATIO。如果ASPECT_RATIO不是在你自己写的头文件中定义的，你就会奇怪1.653是从哪里来的，甚至会花时间跟踪下去。这个问题也会出现在符号调试器中，因为同样地，你所写的符号名不会出现在符号列表中。解决这个问题的方案很简单：不用预处理宏，定义一个常量：constdoubleASPECT_RATIO=1.653;这种方法很有效。但有两个特殊情况要注意。首先，定义指针常量时会有点不同。因为常量定义一般是放在头文件中（许多源文件会包含它），除了指针所指的类型要定义成const外，重要的是指针也经常要定义成const。例如，要在头文件中定义一个基于char*的字符串常量，你要写两次const：constchar*constauthorName=ScottMeyers;关于const的含义和用法，特别是和指针相关联的问题，参见条款21。另外，定义某个类(class)的常量一般也很方便，只有一点点不同。要把常量限制在类中，首先要使它成为类的成员；为了保证常量最多只有一份拷贝，还要把它定义为静态成员：classGamePlayer{private:staticconstintNUM_TURNS=5;//constanteclarationintscores[NUM_TURNS];//useofconstant...};还有一点，正如你看到的，上面的语句是NUM_TURNS的声明，而不是定义，所以你还必须在类的实现代码文件中定义类的静态成员：constintGamePlayer::NUM_TURNS;//mandatorydefinition;//goesinclassimpl.file你不必过于担心这种小事。如果你忘了定义，链接器会提醒你。旧一点的编译器会不接受这种语法，因为它认为类的静态成员在声明时定义初始值是非法的；而且，类内只允许初始化整数类型(如：int,bool,char等)，还只能是常量。在上面的语法不能使用的情况下，可以在定义时赋初值：classEngineeringConstants{//thisgoesintheclassprivate://headerfilestaticconstdoubleFUDGE_FACTOR;...};//thisgoesintheclassimplementationfileconstdoubleEngineeringConstants::FUDGE_FACTOR=1.35;大多数情况下你只要做这么多。唯一例外的是当你的类在编译时需要用到这个类的常量的情况，例如上面GamePlayer::scores数组的声明(编译过程中编译器一定要知道数组的大小)。所以，为了弥补那些(不正确地)禁止类内进行整型类常量初始化的编译器的不足，可以采用称之为“借用enum”的方法来解决。这种技术很好地利用了当需要int类型时可以使用枚举类型的原则，所以GamePlayer也可以象这样来定义：classGamePlayer{private:enum{NUM_TURNS=5}//theenumhack—makes//NUM_TURNSasymbolicname//for5intscores[NUM_TURNS];//fine};除非你正在用老的编译器(即写于1995年之前)，你不必借用enum。当然，知道有这种方法还是值得的，因为这种可以追溯到很久以前的时代的代码可是不常见的哟。回到预处理的话题上来。另一个普遍的#define指令的用法是用它来实现那些看起来象函数而又不会导致函数调用的宏。典型的例子是计算两个对象的最大值：#definemax(a,b)((a)(b)?(a):(b))这个语句有很多缺陷，光想想都让人头疼，甚至比在高峰时间到高速公路去开车还让人痛苦。无论什么时候你写了象这样的宏，你必须记住在写宏体时对每个参数都要加上括号；否则，别人调用你的宏时如果用了表达式就会造成很大的麻烦。但是即使你象这样做了，还会有象下面这样奇怪的事发生：inta=5,b=0;max(++a,b);//a的值增加了2次max(++a,b+10);//a的值只增加了1次这种情况下，max内部发生些什么取决于它比较的是什么值！幸运的是你不必再忍受这样愚笨的语句了。你可以用普通函数实现宏的效率，再加上可预计的行为和类型安全，这就是内联函数(见条款33)：inlineintmax(inta,intb){returnab?a:b;}不过这和上面的宏不大一样，因为这个版本的max只能处理int类型。但模板可以很轻巧地解决这个问题：templateclassTinlineconstT&max(constT&a,constT&b){returnab?a:b;}这个模板产生了一整套函数，每个函数拿两个可以转换成同种类型的对象进行比较然后返回较大的(常量)对象的引用。因为不知道T的类型，返回时传递引用可以提高效率(见条款22)。顺便说一句，在你打算用模板写象max这样有用的通用函数时，先检查一下标准库(见条款49)，看看他们是不是已经存在。比如说上面说的max，你会惊喜地发现你可以后人乘凉：max是C++标准库的一部分。有了const和inline，你对预处理的需要减少了，但也不能完全没有它。抛弃#include的日子还很远，#ifdef/#ifndef在控制编译的过程中还扮演重要角色。预处理还不能退休，但你一定要计划给它经常放长假。--------------------------------------------------------------------------------条款2：尽量用iostream而不用stdio.h是的，scanf和printf很轻巧，很高效，你也早就知道怎么用它们，这我承认。但尽管他们很有用，事实上scanf和printf及其系列还可以做些改进。尤其是，他们不是类型安全的，而且没有扩展性。因为类型安全和扩展性是C++的基石，所以你也要服从这一点。另外，scanf/printf系列函数把要读写的变量和控制读写格式的信息分开来，就象古老的FORTRAN那样。是该向五十年代说诀别的时候了！不必惊奇，scanf/printf的这些弱点正是操作符和的强项:inti;Rationalr;//r是个有理数...cinir;coutir;上面的代码要通过编译，和必须是可以处理Rational类型对象的重载函数(可能要通过隐式类型转换)。如果没有实现这样的函数，就会出错(处理int不用这样做，因为它是标准用法)。另外，编译器自己可以根据不同的变量类型选择操作符的不同形式，所以不必劳你去指定第一个要读写的对象是int而第二个是Rational。另外，在传递读和写的对象时采用的语法形式相同，所以不必象scanf那样死记一些规定，比如如果没有得到指针，必须加上地址符，而如果已经得到了指针，又要确定不要加上地址符。这些完全可以交给C++编译器去做。编译器没别的什么事好做的，而你却不一样。最后要注意的是，象int这样的固定类型和象Rational这样的自定义类型在读写时方式是一样的。而你用sacnf和printf试试看！你所写的表示有理数的类的代码可能象下面这样：classRational{public:Rational(intnumerator=0,intdenominator=1);...private:intn,d;//分子，分母friendostream&operator(ostream&s,constRational&);};ostream&operator(ostream&s,constRational&r){sr.n'/'r.d;returns;}上面的代码涉及到operator的一些微妙(但很重要)的用法，这在本书其他地方详细讨论。例如：上面的operator不是成员函数(条款19解释了为什么)，而且，传递给operator的不是Rational对象，而是定义为const的对象的引用(参见条款22)。operator的声明和实现也类似。尽管我不大愿意承认，可有些情况下回到那些经过证明而且正确的老路上去还是很有意义的。第一，有些iostream的操作实现起来比相应的Cstream效率要低，所以不同的选择会给你的程序有可能(虽然不一定，参见条款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，那头文件名的使用会很微妙。例如，如果使用了#includeiostream,得到的是置于名字空间std(见条款28)下的iostream库的元素；如果使用#includeiostream.h，得到的是置于全局空间的同样的元素。在全局空间获取元素会导致名字冲突，而设计名字空间的初衷正是用来避免这种名字冲突的发生。还有，打字时iostream比iostream.h少两个字，这也是很多人用它的原因。:)--------------------------------------------------------------------------------条款3：尽量用new和del