lostmouse的专栏

  条款38: 决不要重新定义继承而来的缺省参数值让我们从一开始就把问题简化。缺省参数只能作为函数的一部分而存在；另外，只有两种函数可以继承：虚函数和非虚函数。因此，重定义缺省参数值的唯一方法是重定义一个继承而来的函数。然而，重定义继承而来的非虚函数是一种错误（参见条款37），所以，我们完全可以把讨论的范围缩小为 "继承一个有缺省参数值的虚函数" 的情况。既然如此，本条款的理由就变

条款43: 明智地使用多继承要看是谁来说，多继承（MI）要么被认为是神来之笔，要么被当成是魔鬼的造物。支持者宣扬说，它是对真实世界问题进行自然模型化所必需的；而批评者争论说，它太慢，难以实现，功能却不比单继承强大。更让人为难的是，面向对象编程语言领域在这个问题上至今仍存在分歧：C++，Eiffel和the Common LISP Object System (CLOS)提供了MI；Smallt

条款41: 区分继承和模板考虑下面两个设计问题：· 作为一位立志献身计算机科学的学生，你想设计一个类来表示对象的堆栈。这将需要多个不同的类，因为每个堆栈中的元素必须是同类的，即，它里面包含的必须只是同种类型的对象。例如，会有一个类来表示int的堆栈，第二个类来表示string的堆栈，第三个类来表示string的堆栈的堆栈，等等。你也许对设计一个最小的类接口（参见条款18）很感兴趣，所以会将

条款31: 千万不要返回局部对象的引用，也不要返回函数内部用new初始化的指针的引用本条款听起来很复杂，其实不然。它只是一个很简单的道理，真的，相信我。先看第一种情况：返回一个局部对象的引用。它的问题在于，局部对象 ----- 顾名思义 ---- 仅仅是局部的。也就是说，局部对象是在被定义时创建，在离开生命空间时被销毁的。所谓生命空间，是指它们所在的函数体。当函数返回时，程序的控制离开了这

条款28: 划分全局名字空间全局空间最大的问题在于它本身仅有一个。在大的软件项目中，经常会有不少人把他们定义的名字都放在这个单一的空间中，从而不可避免地导致名字冲突。例如，假设library1.h定义了一些常量，其中包括：const double LIB_VERSION = 1.204;类似的，library2.h也定义了：const int LIB_VERSION = 3;很

条款15: 让operator=返回*this的引用C++的设计者Bjarne Stroustrup下了很大的功夫想使用户自定义类型尽可能地和固定类型的工作方式相似。这就是为什么你可以重载运算符，写类型转换函数（见条款M5），控制赋值和拷贝构造函数，等等。他做了这么多努力，那你最少也该继续做下去。让我们看看赋值。用固定类型的情况下，赋值操作可以象下面这样链起来：int w, x, y,

条款7：预先准备好内存不够的情况operator new在无法完成内存分配请求时会抛出异常(以前的做法一般是返回0，一些旧一点的编译器还这么做。你愿意的话也可以把你的编译器设置成这样。关于这个话题我将推迟到本条款的结尾处讨论)。大家都知道，处理内存不够所产生的异常真可以算得上是个道德上的行为，但实际做起来又会象刀架在脖子上那样痛苦。所以，你有时会不去管它，也许一直没去管它。但你心里一定还是深深

 条款2：尽量用而不用是的，scanf和printf很轻巧，很高效，你也早就知道怎么用它们，这我承认。但尽管他们很有用，事实上scanf和printf及其系列还可以做些改进。尤其是，他们不是类型安全的，而且没有扩展性。因为类型安全和扩展性是C++的基石，所以你也要服从这一点。另外，scanf/printf系列函数把要读写的变量和控制读写格式的信息分开来，就象古老的FORTRAN那样。是该向

条款44: 说你想说的；理解你所说的在本章关于 "继承和面向对象设计" 的简介中，我曾强调，理解不同的面向对象构件在C++中的含义十分重要。这和仅仅知道C++语言的规则有很大的不同。例如，C++规则说，如果类D从类B公有继承，从D的指针到B的指针就有一个标准转换；B的公有成员函数将被继承为D的公有成员函数，等等。这些规则都是正确的，但在将设计思想转化为C++的过程中，它们起不到任何作用。相反，

 条款40: 通过分层来体现 "有一个" 或 "用...来实现"使某个类的对象成为另一个类的数据成员，从而实现将一个类构筑在另一个类之上，这一过程称为 "分层"(Layering)。例如：class Address { ... };           // 某人居住之处class PhoneNumber { ... };class Person {public:  ...

条款33: 明智地使用内联内联函数------多妙的主意啊！它们看起来象函数，运作起来象函数，比宏(macro)要好得多（参见条款1），使用时还不需要承担函数调用的开销。你还能对它们要求更多吗？然而，你从它们得到的确实比你想象的要多，因为避免函数调用的开销仅仅是问题的一个方面。为了处理那些没有函数调用的代码，编译器优化程序本身进行了专门的设计。所以当内联一个函数时，编译器可以对函数体执行特

条款47: 确保非局部静态对象在使用前被初始化大家都是成年人了，所以用不着我来告诉你们：使用未被初始化的对象无异于蛮干。事实上，关于这个问题的整个想法会让你觉得可笑；构造函数可以确保对象在创建时被初始化，难道不是这样吗？唔，是，也不是。在某个特定的被编译单元（即，源文件）中，可能一切都不成问题；但如果在某个被编译单元中，一个对象的初始化要依赖于另一个被编译单元中的另一个对象的值，并且这第二

条款48: 重视编译器警告很多程序员日常总是不理睬编译器警告。毕竟，如果问题很严重，就会是个错误，不是吗？这种想法在其它语言中相对来说没什么害处，但在C++中，可以肯定的一点是，编译器的设计者肯定比你更清楚到底发生了什么。例如，大家可能都犯过这个错误：class B {public:  virtual void f() const;};class D: public B {public

条款49: 熟悉标准库C++标准库很大。非常大。难以置信的大。怎么个大法？这么说吧：在C++标准中，关于标准库的规格说明占了密密麻麻300多页，这还不包括标准C库，后者只是 "作为参考"（老实说，原文就是用的这个词）包含在C++库中。当然，并非总是越大越好，但在现在的情况下，确实越大越好，因为大的库会包含大量的功能。标准库中的功能越多，开发自己的应用程序时能借助的功能就越多。C++库并非提

条款34: 将文件间的编译依赖性降至最低假设某一天你打开自己的C++程序代码，然后对某个类的实现做了小小的改动。提醒你，改动的不是接口，而是类的实现，也就是说，只是细节部分。然后你准备重新生成程序，心想，编译和链接应该只会花几秒种。毕竟，只是改动了一个类嘛！于是你点击了一下"Rebuild"，或输入make（或其它类似命令）。然而，等待你的是惊愕，接着是痛苦。因为你发现，整个世界都在被重新编译

条款30: 避免这样的成员函数：其返回值是指向成员的非const指针或引用，但成员的访问级比这个函数要低使一个成员为private或protected的原因是想限制对它的访问，对吗？劳累的编译器要费九牛二虎之力来确保你设置的访问限制不被破坏，对不对？所以，写个函数来让用户随意地访问受限的成员没多大意义，对不对？如果你确实认为有意义，那么请反复阅读本段，直到你不这样认为为止。实际编程中很容易

条款24: 在函数重载和设定参数缺省值间慎重选择会对函数重载和设定参数缺省值产生混淆的原因在于，它们都允许一个函数以多种方式被调用：void f();                             // f被重载void f(int x);f();                                  // 调用f()f(10);                 

条款21: 尽可能使用const使用const的好处在于它允许指定一种语意上的约束——某种对象不能被修改——编译器具体来实施这种约束。通过const，你可以通知编译器和其他程序员某个值要保持不变。只要是这种情况，你就要明确地使用const ，因为这样做就可以借助编译器的帮助确保这种约束不被破坏。const关键字实在是神通广大。在类的外面，它可以用于全局或名字空间常量（见条款1和47），以及

条款20: 避免public接口出现数据成员首先，从“一致性”的角度来看这个问题。如果public接口里都是函数，用户每次访问类的成员时就用不着抓脑袋去想：是该用括号还是不该用括号呢？——用括号就是了！因为每个成员都是函数。一生中，这可以避免你多少次抓脑袋啊！你不买“一致性”的帐？那你总得承认采用函数可以更精确地控制数据成员的访问权这一事实吧？如果使数据成员为public，每个人都可以对它

条款13: 初始化列表中成员列出的顺序和它们在类中声明的顺序相同顽固的Pascal和Ada程序员会经常想念那种可以任意设定数组下标上下限的功能，即，数组下标的范围可以设为10到20，不一定要是0到10。资深的C程序员会坚持一定要从0开始计数，但想个办法来满足那些还在用begin/end的人的这个要求也很容易，这只需要定义一个自己的Array类模板：templateclass Array {

构造函数，析构函数和赋值操作符几乎所有的类都有一个或多个构造函数，一个析构函数和一个赋值操作符。这没什么奇怪的，因为它们提供的都是一些最基本的功能。构造函数控制对象生成时的基本操作，并保证对象被初始化；析构函数摧毁一个对象并保证它被彻底清除；赋值操作符则给对象一个新的值。在这些函数上出错就会给整个类带来无尽的负面影响，所以一定要保证其正确性。本章我将指导如何用这些函数来搭建一个结构良好的类的主

条款6：析构函数里对指针成员调用delete大多数情况下，执行动态内存分配的的类都在构造函数里用new分配内存，然后在析构函数里用delete释放内存。最初写这个类的时候当然不难做，你会记得最后对在所有构造函数里分配了内存的所有成员使用delete。然而，这个类经过维护、升级后，情况就会变得困难了，因为对类的代码进行修改的程序员不一定就是最早写这个类的人。而增加一个指针成员意味着几乎都要进

内存管理C++中涉及到的内存的管理问题可以归结为两方面：正确地得到它和有效地使用它。好的程序员会理解这两个问题为什么要以这样的顺序列出。因为执行得再快、体积再小的程序如果它不按你所想象地那样去执行，那也一点用处都没有。“正确地得到”的意思是正确地调用内存分配和释放程序；而“有效地使用”是指写特定版本的内存分配和释放程序。这里，“正确地得到”显得更重要一些。然而说到正确性，C++其实从C继承

条款3：尽量用new和delete而不用malloc和freemalloc和free(及其变体)会产生问题的原因在于它们太简单：他们不知道构造函数和析构函数。假设用两种方法给一个包含10个string对象的数组分配空间，一个用malloc，另一个用new：　　　　string *stringArray1 =  　　　　static_cast(malloc(10 * sizeof(strin

条款32: 尽可能地推迟变量的定义是的，我们同意C语言中变量要放在模块头部定义的规定；但在C++中，还是取消这种做法吧，它没必要，不自然，而且昂贵。还记得吗？如果定义了一个有构造函数和析构函数的类型的变量，当程序运行到变量定义之处时，必然面临构造的开销；当变量离开它的生命空间时，又要承担析构的开销。这意味着定义无用的变量必然伴随着不必要的开销，所以只要可能，就要避免这种情况发生。正如我

条款27: 如果不想使用隐式生成的函数就要显式地禁止它假设想写一个类模板Array，它所生成的类除了可以进行上下限检查外，其它行为和C++标准数组一样。设计中面临的一个问题是怎么禁止掉Array对象之间的赋值操作，因为对标准C++数组来说赋值是不合法的：double values1[10];double values2[10];values1 = values2;           

条款36: 区分接口继承和实现继承（公有）继承的概念看起来很简单，进一步分析，会发现它由两个可分的部分组成：函数接口的继承和函数实现的继承。这两种继承类型的区别和本书简介中所讨论的函数声明和函数定义间的区别是完全一致的。作为类的设计者，有时希望派生类只继承成员函数的接口（声明）；有时希望派生类同时继承函数的接口和实现，但允许派生类改写实现；有时则希望同时继承接口和实现，并且不允许派生类改写

继承和面向对象设计很多人认为，继承是面向对象程序设计的全部。这个观点是否正确还有待争论，但本书其它章节的条款数量足以证明，在进行高效的C++程序设计时，还有更多的工具听你调遣，而不仅仅是简单地让一个类从另一个类继承。然而，设计和实现类的层次结构与C语言中的一切都有着根本的不同。只有在继承和面向对象设计领域，你才最有可能从根本上重新思考软件系统构造的方法。另外，C++提供了多种很令人困惑的面

类和函数: 实现C++是一种高度类型化的语言，所以，给出合适的类和模板的定义以及合适的函数声明是整个设计工作中最大的一部分。按理说，只要这部分做好了，类、模板以及函数的实现就不容易出问题。但是，往往人们还是会犯错。犯错的原因有的是不小心违反了抽象的原则：让实现细节可以提取类和函数内部的数据。有的错误在于不清楚对象生命周期的长短。还有的错误起源于不合理的前期优化工作，特别是滥用inline关

条款26: 当心潜在的二义性每个人都有思想。有些人相信自由经济学，有些人相信来生。有些人甚至相信COBOL是一种真正的程序设计语言。C++也有一种思想：它认为潜在的二义性不是一种错误。这是潜在二义性的一个例子：class B;                    // 对类B提前声明                            // class A {public:  A(

条款25: 避免对指针和数字类型重载快速抢答：什么是“零”？更明确地说，下面的代码会发生什么？void f(int x);void f(string *ps);f(0);                        // 调用f(int)还是f(string*)?答案是，0是一个int——准确地说，一个字面上的整数常量——所以，“总是”f(int)被调用。这就是问题所在：因为

条款22: 尽量用“传引用”而不用“传值”C语言中，什么都是通过传值来实现的，C++继承了这一传统并将它作为默认方式。除非明确指定，函数的形参总是通过“实参的拷贝”来初始化的，函数的调用者得到的也是函数返回值的拷贝。正如我在本书的导言中所指出的，“通过值来传递一个对象”的具体含义是由这个对象的类的拷贝构造函数定义的。这使得传值成为一种非常昂贵的操作。例如，看下面这个（只是假想的）类的结构：

 条款19: 分清成员函数，非成员函数和友元函数成员函数和非成员函数最大的区别在于成员函数可以是虚拟的而非成员函数不行。所以，如果有个函数必须进行动态绑定（见条款38），就要采用虚拟函数，而虚拟函数必定是某个类的成员函数。关于这一点就这么简单。如果函数不必是虚拟的，情况就稍微复杂一点。看下面表示有理数的一个类：class Rational {public:  Rational(in

类和函数：设计与声明在程序中声明一个新类将导致产生一种新的类型：类的设计就是类型设计。可能你对类型设计没有太多经验，因为大多数语言没有为你提供实践的机会。在C++中，这却是很基本的特性，不是因为你想去做才可以这么做，而是因为每次你声明一个类的时候实际上就在做，无论你想不想做。设计一个好的类很具有挑战性，因为设计好的类型很具有挑战性。好的类型具有自然的语法，直观的语义和高效的实现。在C++中

 条款17: 在operator=中检查给自己赋值的情况做类似下面的事时，就会发生自己给自己赋值的情况：class X { ... };X a;a = a;                     // a赋值给自己这种事做起来好象很无聊，但它完全是合法的，所以看到程序员这样做不要感到丝毫的怀疑。更重要的是，给自己赋值的情况还可以以下面这种看起来更隐蔽的形式出现：

条款16: 在operator=中对所有数据成员赋值条款45说明了如果没写赋值运算符的话，编译器就会为你生成一个，条款11则说明了为什么你会经常不喜欢编译器为你生成的这个赋值运算符，所以你会想能否有个两全其美的办法，让编译器生成一个缺省的赋值运算符，然后可以有选择地重写不喜欢的部分。这是不可能的！只要想对赋值过程的某一个部分进行控制，就必须负责做赋值过程中所有的事。实际编程中，这意味着写赋

条款37: 决不要重新定义继承而来的非虚函数有两种方法来看待这个问题：理论的方法和实践的方法。让我们先从实践的方法开始。毕竟，理论家一般都很耐心。假设类D公有继承于类B，并且类B中定义了一个公有成员函数mf。mf的参数和返回类型不重要，所以假设都为void。换句话说，我这么写：class B {public:  void mf();  ...};class D: public B

条款39: 避免 "向下转换" 继承层次在当今喧嚣的经济时代，关注一下我们的金融机构是个不错的主意。所以，看看下面这个有关银行帐户的协议类(Protocol class )（参见条款34）：class Person { ... };class BankAccount {public:  BankAccount(const Person *primaryOwner,           

条款42: 明智地使用私有继承条款35说明，C++将公有继承视为 "是一个" 的关系。它是通过这个例子来证实的：假如某个类层次结构中，Student类从Person类公有继承，为了使某个函数成功调用，编译器可以在必要时隐式地将Student转换为Person。这个例子很值得再看一遍，只是现在，公有继承换成了私有继承：class Person { ... };class Student:

条款23: 必须返回一个对象时不要试图返回一个引用据说爱因斯坦曾提出过这样的建议：尽可能地让事情简单，但不要过于简单。在C++语言中相似的说法应该是：尽可能地使程序高效，但不要过于高效。一旦程序员抓住了“传值”在效率上的把柄（参见条款22），他们会变得十分极端，恨不得挖出每一个隐藏在程序中的传值操作。岂不知，在他们不懈地追求纯粹的“传引用”的过程中，他们会不可避免地犯另一个严重的错误：传递