static const int NumTurns = 5；//static 静态常量 所有的对象只有一份拷贝。     万一你编译器不允许“static整数型class常量”完成“in calss初值设定”（即在类的声明中设定静态整形的初值），我们可以通过枚举类型予以补偿：       enum { NumTurns = 5 }；     *取一个const的地址是合法的，但取一个enum的地址就不合法，而取一个#define的地址通常也不合法。如果你不想让别人获取一个pointer或reference指向你的某个整数常量，enum可以帮助你实现这个约束。      例：#define CALL_WITH_MAX(a,b)    f((a) > (b)) ? (a) : (b))      宏看起来像函数，但不会招致函数调用带来的额外开销，而是一种简单的替换。      替换：       template<typename T>
      inline void callWithMax(cosnt T &a, cosnt T &b)
      {
            f(a > b ? a : b);
       }       callWithMax是个真正的函数，它遵循作用于和访问规则。       请记住：

• 对于单纯常量，最好以const对象或enums替换#defines；
• 对于形似函数的宏，最好改用inline函数替换#defines。       

    条款03：尽可能使用const
    const允许你告诉编译器和其他程序员某值应保持不变，只要“某值”确实是不该被改变的，那就该确实说出来。     关键字const多才多艺：     例：
        char greeting[] = "Hello";
        char *p = greeting;    //指针p及所指的字符串都可改变；
        const char *p = greeting;    //指针p本身可以改变，如p = &Anyother；p所指的字符串不可改变；
        char * cosnt p = greeting;    //指针p不可改变，所指对象可改变；
        const char * const p = greeting;    //指针p及所致对象都不可改变；      说明：

• 如果关键字const出现在星号左边，表示被指物事常量。const char *p和char const *p两种写法意义一样，都说明所致对象为常量；
• 如果关键字const出现在星号右边，表示指针自身是常量。   

    STL例子：         const std::vector<int>::interator iter = vec.begin();//作用像T *const, ++iter 错误：iter是const
        std::vector<int>::const_iterator cIter = vec.begin();//作用像const T*，*cIter = 10 错误：*cIter是const     以下几点注意：

• 令函数返回一个常量值，往往可以降低因客户错误而造成的意外，而不至于放弃安全性和高效性。

    条款12：复制对象时勿忘其每一个成员     还记得条款5中提到编译器在必要时会为我们提供拷贝构造函数和拷贝赋值函数，它们也许工作的不错，但有时候我们需要自己编写自己的拷贝构造函数和拷贝赋值函数。如果这样，我们应确保对“每一个”成员进行拷贝（复制）。     如果你在类中添加一个成员变量，你必须同时修改相应的copying函数（所有的构造函数，拷贝构造函数以及拷贝赋值操作符）。     在派生类的构造函数，拷贝构造函数和拷贝赋值操作符中应当显示调用基类相对应的函数，否则编译器可能又“自作聪明了”。      当你编写一个copying函数，请确保：   

    在资源管理方面，也许我们应该“先发制人”，即让函数返回一个资源的指针改为返回一个只能指针。      例如：      std::tr1::shared_ptr<Investment> createInvestment();     这便实质上强迫客户将返回值存储于一个tr1::shared_ptr内，几乎消除了忘记删除底部Investment对象的可能性。     tr1::shared_ptr提供的某个构造函数接受两个实参：一个是被管理的指针，另一个是引用次数变成0时被调用的“删除器”。但我们自己制定第二个参数，当然这是安全的。但是留给客户，那也许存在危险。      std::tr1::shared_ptr<Investment>         //tr1::shared_ptr构造函数坚持第一个参数必须是个指针。                 pInv(static_cast<Investment*>(0), getRidOfInvestment);     tr1::shared_ptr有一个特别好的性质是：它会自动使用它的“每个指针专属的删除器”，因而消除另一个潜在的客户错误：所谓的“cross-DLL problem”。因为它缺省的删除器是来自“tr1::shared_ptr诞生所在的那个DLL”的delete。      请记住：

• 好的接口很容易被正确使用，不容易被误用。你应该在你的所有接口中努力达成这些性质。
• “促进正确使用”的办法包括接口的一致性，以及与内置类型的行为兼容。
• “阻止误用”的办法包括建立新类型、限制类型上的操作，束缚对象值，以及消除客户的资源管理责任。
• tr1::shared_ptr支持定制删除器。这可防范DLL问题，可被用来自动解除互斥量等等。   

    条款19：设计class犹如设计type     C++就像在其它面向对象编程语言一样，当你定义一个新class，也就定义了一个新type。这意味着你并不只是类的设计者，更是类型的设计者。重载函数和操作符、控制内存的分配和归还、定义对象的初始化和终结......全部在你手上。     设计优秀的类是一项艰巨的工作，因为涉及好的类型是一项艰巨的工作。好的类型有自然的语法，直观的语义，以及一或多个高效实现品。     设计一个良好的类，或者称作类型，考虑一下设计规范：

• 新类型的对象应该如何被创建和销毁？
• 对象的初始化和对象的赋值该有什么样的差别？
• 新类型的对象如果被passed by value（值传递），意味着什么？
• 什么是新类型的“合法值”？
• 你的新类型需要配合某个继承图系吗？
• 你的新类型需要什么样的转换？
• 什么样的操作符和函数对此新类型而言是合理的？
• 什么样的标准函数应该驳回？
• 谁该取用新类型的成员？
• 什么是新类型的“未声明接口”？
• 你的新类型有多少一般化？
• 你真的需要一个新类型吗？   

    请记住：

• Class的设计就是type的设计。在定义一个新的type之前，请确定你已经考虑过本条款覆盖的所有讨论主题。   

    条款20：宁以pass-by-reference-to-const替代psss-by-value     缺省情况下C++以by value方式传递对象至函数。除非你另外指定，否则函数参数都是以实际实参的副本为初值，而调用端所获得的亦是返回值的一个副本。这些副本由对象的拷贝构造函数产生。     所以在以对象为by value时，可能会调用相应的构造函数（成员对象的构造、基类对象的构造），然后调用对应的析构函数。所以以by value的形式开销还是比较大的。      如果我们用pass-by-reference-to-const，例如：      bool validateStudent(const Student& s);     //const，希望别对传入对象进行不恰当的修改；      这种传递方式效率高得多：没有任何构造函数或析构函数被调用，因为没有任何新对象被创建。     以传引用方式传递参数也可以避免对象切割问题：即当一个派生类对象以传值的方式传递并被视为一个基类对象，基类对象的拷贝构造函数会被调用，而“造成此对象的行为像个派生类对象”的那些特化性质全被切割掉了，仅仅留下了基类对象。这一般不是你想要的。     所以我们一般的做法应该是这样：内置对象和STL的迭代器和函数对象，我们一般以传值的方式传递，而其它的任何东西都以传引用的方式传递。     请记住：

• 尽量以pass-by-reference-to-const替代pass-by-value。前者通常比较高效，并可避免切割问题。
• 以上规则并不使用于内置类型，以及STL的迭代器和函数对象。对它们而言，pass-by-value往往比较适当。   

    条款21：必须返回对象时，别妄想返回其reference     当我们领悟条款20中传值的开销后，总是避免于少用传值，然而在返回对象时，要格外小心了，因为你可能：传递一些引用或指针指向其实已经不存在的对象。这可不是件好事。     任何时候看到一个reference声明式，你都应该立刻问自己，它的另一个名称是什么？     函数创建新对象的途径有二：在栈空间和堆空间      栈上：即在函数内的局部变量。局部变量在函数返回后就没有存在的意义，若还对它“念念不忘”，将带来灾难性后果。所以传引用在栈上不可行。      堆上：在堆上构造一个对象，并返回。看似可行，也埋下了资源泄漏的危险。谁该对这对象实施delete呢？别把这种对资源的管理寄托完全寄托于用户。所以传引用在堆上不可行。     可能还有一种想法：把“让返回的引用指向一个被定义于函数内部的静态对象”。出于我们对多线程安全性的疑虑，以及当线程中两个函数对单份对象的处理也可能带来不可测行为。所以静态对象也是不可行的。     一个“必须返回新对象”的函数的正确写法是：就让那个函数返回一个新对象。     编译器实现者实行最优化，用以改善产出码的效率却不改变其观察的行为。所以我们还是老老实实的返回一个对象吧。     请记住：

• 绝不要返回pointer或reference指向一个local stack对象，或返回reference指向一个heap-allocated对象，或返回pointer或reference指向一个local static对象而有可能同时需要多个这样的对象。   

    条款22：将成员变量声明为private     将成员变量隐藏在函数接口的背后，可以为“所有可能的实现”提供弹性。例如,这可使得成员变量被读或写时轻松通知其它对象、可以验证calss的约束条件以及函数的前提和事后状态、可以在多线程环境中执行同步控制......      不封装意味不可改变！成员变量的封装性与“成员变量的内容改变时所坏量的代码数量”成反比。      请记住：

• 切记将成员变量声明为private。这可赋予客户访问数据的一致性、可细微划分访问控制、允许约束条件获得保护，并提供class作者以充分的实现弹性。
• protected并不比public更具封装性。   

    条款23：宁以non-member、non-friend替换member函数     一般我们相当然以为类中的成员函数更具封装性，而实际上并不是那么一回事，因为成员函数不仅可以访问private成员变量，也可以取用private函数、enums、typedefs等等。而非成员非友元函数能实现更大的封装性，因为它只能访问public函数。     将所有便利函数放在多个头文件内但隶属同一个命名空间，意味客户可以轻松扩展这一组便利函数。需要做的就是添加更多non-member non-friend函数到此命名空间内。     请记住：

• 宁可拿non-member non-friend函数替代member函数。这样做可以增加封装性、包裹弹性和机能扩充性。   

    条款24：若所有参数皆需类型转换，请为此采用non-member函数     通常，令类支持隐式类型转换通常是个糟糕的主意。当然这条规则有其例外，最常见的例外是在建立数值类型时。      例：      const Rational operator*(const Rational& rhs) const;      如果定义一个有理数类，并实现*操作符为成员函数，如上所示；那么考虑一下调用：      Rational oneHalf(1, 2);      result = oneHalf * 2; // 正确，2被隐式转换为Rational（2，1）                                      //编译器眼中应该是这样：const Rational temp(2); result = oneHalf * temp;      result = 2 * oneHalf; // 错误，2，可不被认为是Rational对象；因此无法调用operator*     可见，这样并不准确，因为乘法（*）应该满足交换律，不是吗？     所以，支持混合式算术运算的可行之道应该是：让operator*成为一个non-member函数，允许编译器在每一个实参上执行隐式类型转换：      class Rational     {         ... // contains no operator*     };      const Rational operator*(const Rational& lhs,  Rational& rhs)     {         return Rational(lhs.numerator() * rhs.numerator(),                                 lhs.denominator() * rhs.denominator());     }     Rational oneFourth(1, 4);      Rational result;      result = oneFourth * 2;      result = 2 * oneFourth;  //这下两个都工作的很好，通过隐式转换实现     成员函数的方面是非成员函数，而不是友元函数。     可以用类中的public接口实现的函数，最好就是非成员函数，而不是采用友元函数。     请记住：

• 如果你需要为某个函数的所有参数（包括被this指针所指的那个隐喻参数）进行类型转换，那么这个函数必须是个non-member。   

    条款25：考虑写出一个不抛异常的swap函数     ......     请记住：

• 当std::swap对你的类型效率不高时，提供一个swap成员函数，并确定这个函数不抛出异常。
• 如果你提供一个member swap，也该提供一个non-member swap用来调用前者。对于class（而非templates），也请特化std::swap。
• 调用swap时应针对std::swap使用using声明式，然后调用swap并且不带任何“命名空间资格修饰”。
• 为“用户定义类型”进行std templates全特化是好的，但千万不要尝试在std内加入某些对std而言全新的东西。   

五.实现        大多数情况下，适当提出拟的类定义以及函数声明，是花费最多心力的两件事。尽管如此，还是有很多东西需要小心：太快定义变量可能造成效率上的拖延；过度使用转型（casts）可能导致代码变慢又难维护，又招来微妙难解的错误；返回对象“内部数据之号码牌（handls）”可能会破坏封装并留给客户虚吊号码牌；为考虑异常带来的冲击则可能导致资源泄漏和数据败坏；过度热心地inlining可能引起代码膨胀；过度耦合则可能导致让人不满意的冗长建置时间。   

    条款26：尽可能延后变量定义式的出现时间     只要你定义了一个变量而其类型带有一个构造函数或析构函数，那么当程序的控制流到达这个变量定义式时，你便得承受构造成本；当这个变量离开其作用域时，你便得承受析构成本。即使这个变量最终并为被使用，仍需耗费这些成本，所以应该尽量避免这种情形。     std::string encryptPassword(const std::string& password)     {         using namespace std;         string encrypted¹;         if (password.length() < MinimumPasswordLength)         {             throw logic_error("Password is too short");     //注意：可能抛出异常         }         string encrypted²;          ...         return encrypted;      }     如上代码，encrypted在2处定义是个不错的选择，因为如果抛出异常，那么encrypted的构造和析构可是做了无用功啊！      还有一点要注意：“通过默认构造函数构造出一个对象然后对它赋值”比“直接在构造函数时制定初值”效率差。      “尽可能延后”的真正意义应该是：你不只应该延后变量的定义，直到非得使用该变量的前一刻为止，甚至应该尝试延后这份定义直到能够给它初值实参为止。      //方法A:定义循环外     Widget w;      for (int i = 0; i < n; ++i)     {         w = some value dependent on i;         ...     }     //1个构造函数+1个析构函数+n个赋值操作；     //方法B：定义循环外      for (int i = 0; i < n; ++i)     {         Widget w(some value dependent on i);          ...     }     //n个构造函数+n个析构函数     除非：1.你知道赋值成本比“构造+析构”成本低；2.你正在处理代码中效率高度敏感的部分，否则应该使用方法B。     请记住：

• 尽可能延后变量定义式的出现。这样做可增加程序的清晰度并改善程序效率。   

    条款27：尽量少做转型动作     C++规则的设计目标之一是，保证“类型错误”绝不可能发生。不幸的是，转型（casts）破坏了类型系统。那可能导致任何种类的麻烦，有些容易辨识，有些非常隐晦。     C风格的转型动作看起来像这样：      (T)expression    //将expression转型为T      函数风格的转型动作看起来像这样：      T(expression)    //将expression转型为T     C++还提供四种新式转型：      const_cast:通常被用来将对象的常量性转除；即去掉const。      dynamic_cast:主要用来执行“安全向下转型”，也就是用来决定某对象是否归属继承体系中的某个类型。      reinterpret_cast:意图执行低级转型，实际动作可能取决于编译器，这也就表示它不可移植。      static_cast:用来强迫隐式转换，例如将non-const转型为const，int转型为double等等。     尽量使用新式转型：

• 它们很容易在代码中被辨识出来，因而得以简化“找出类型系统在哪个地点被破坏”的过程。
• 各转型动作的目标愈窄化，编译器愈可能诊断出错误的运用。   

    请记住：

• 如果可以，尽量避免转型，特别是在注重效率的代码中避免dynamic_casts。如果有个设计需要转型动作，试着发展无需转型的替代设计。
• 如果转型是必要的，试着将它隐藏于某个函数背后。客户随后可以调用该函数，而不需将转型放进他们自己的代码内。
• 宁可使用C++-style（新式）转型，不要使用旧式转型。前者很容易辨识出来，而且也比较有着分门别类的执掌。   

    条款28：避免返回handls指向对象内部成分     struct RectData      {         Point ulhc;         Point lrhc;      };     class Rectangle     {         public:             ...             Point& upperLeft() const { return pData->ulhc; }¹//const只对函数内进行保护，函数返回后呢？？             Point& lowerRight() const { return pData->lrhc; }² //const只对函数内进行保护，函数返回后呢？？         private:             std::tr1::shared_ptr<RectData> pData;             ...     };     1，2两函数都返回引用，指向private内部数据，调用者于是可通过这些引用更改内部数据！这严重破坏了数据的封装性，对私有成员进行直接操作？太不可思意了！      const Point& upperLeft() const { return pData->ulhc; }³        const Point& lowerRight() const { return pData->lrhc; }⁴            或者将1，2改为3，4，这就限制了客户的“涂改权”，只有“读取权”。     但终究“返回一个handle代表对象内部成分”总是危险的。特别是将返回的指针或引用赋值给其它指针或引用，那么久造成了“悬空”。     请记住：

• 避免返回handles（包括reference、指针、迭代器）指向对象内部。遵守这个条款可增加封装性，帮助const成员函数的行为像个const，并将发生“虚吊号码牌”（dangling handles）的可能性降至最低。   

    条款29：为“异常安全”而努力是值得的     请记住：

• 异常安全函数（Exception-safe functions）即使发生异常也不会泄漏资源或允许任何数据结构败坏。这样的函数区分为三种可能的保证：基本型、强烈型、不抛异常型。
• “强烈保证”往往能够以copy-and-swap实现出来，但“强烈保证”并非对所有函数都可实现或具备现实意义。
• 函数提供的“异常安全保证”通常最高只等于其所调用之各个函数的“异常安全保证”中的最弱者。   

    条款30：透彻了解inlining的里里外外     Inline函数，多棒的点子！它们看起来像函数，动作像函数，比宏好得多，可以调用它们又不需蒙受函数调用所招致的额外开销。你实际获得的比想象的还多，编译器有能力对执行语境相关最优化。然而编写程序就像现实生活一样，没有白吃的午餐。inline函数也不例外，这样做可能增加你的目标码。      如果inline函数的本体很小，编译器针对“函数本体”所产生的码可能比针对“函数调用”所产出的码更小。果真如此，将函数inlining确实可能导致较小的目标码和较高的指令高速缓存装置击中率。      记住，inline只是对编译器的一个申请，不是强制命令。这项申请可以隐喻提出，也可以明确提出。隐喻方式是将函数定义于class定义式内,这样的函数通常是成员函数，friend函数也可被定义于class内，如果真是那样，它们也是被隐喻声明为inline。明确声明inline函数的做法则是在其定义式钱加上关键字inline。      Inline函数通常一定被置于头文件内，因为大多数建置环境在编译过程中进行inlining，而为了将一个“函数调用”替换为“被调用函数的本体”，编译器必须知道那个函数长什么样子。      Template通常也被置于头文件内，因为它一旦被使用，编译器为了将它具现化，需要知道哦啊它长什么样子。      Template的具现化与inlining无关。如果你正在写一个template而你认为所有根据此template具现出来的函数都应该inlined，请将此template声明为inline；但如果你写的template煤油理由要求它所具现的每一个函数都是inlined，就应该避免将这个template声明为inline。      一个表面上看似inline的函数是否真实inline，取决于你的建置环境，主要取决于编译器。      有的时候虽然编译器有意愿inlining某个函数，还是可能为该函数生成一个函数本体（函数指针，构造函数，析构函数）。      对程序开发而言，将上述所有考虑牢记在新很是重要，但若从纯粹实用观点出发，有一个事实比其它因素更重要：大部分调试器面对inline函数都束手无策。      这使我们在决定哪些函数该被声明为inline而哪些函数不该时，掌握一个合乎逻辑的策略。一开始先不要将任何函数声明为inline，或至少将inlining施行范围局限在那些“一定成为inline”或“十分平淡无奇”的函数身上。      请记住：

• 将大多数inlining限制在小型、被频繁调用的函数身上。这可使日后的调试过程和二进制升级更容易，也可使潜在的代码膨胀问题最小化，是程序的速度提升机会最大化。
• 不要只因为function templates出现在头文件，就将它们声明为inline。   

     条款31：将文件间的编译依存关系降至最低      请记住：

• 支持“编译依存性最小化”的一般构想是：相依于声明式，不要相依于定义式。基于此构想的两个手段是Handle classed和Interface classes。
• 程序库头文件应该以“完全且仅有声明式”（full and declaration-only forms）的形式存在。这种做法不论是否涉及templates都适用。   

六.继承与面向对象设计     如果你了解C++各种特性的意义，你会发现，你对OOP的看法改变了。它不再是一项用来划分语言特性的仪典，而是可以让你通过它说出你对软件系统的想法。一旦你知道该通过它说些什么，移转至C++世界也就不再是可怕的高要求了。

    条款32：确定你的public继承塑模出is-a关系     以C++进行面向对象编程，最重要的一个规则是：public inheritance（公有继承）意味is-a（是一种）的关系。     如果你令class D以public形式继承class B，你便是告诉C++编译器（以及你的代码读者）说，每一个类型为D的对象同时也是一个类型为B的对象，反之不成立。你的意思是B比D表现出更一般化得概念，而D比B表现出更特殊化的概念。你主张：“B对象可派上用场的任何地方，D对象一样可以派上用场”，因为每一个D对象都是一种（是一个）B对象。反之如果你需要一个D对象，B对象无法效劳，因为虽然每个D对象都是一个B对象，反之并不成立。      在C++领域中，任何函数如果期望获得一个类型为基类的实参（而不管是传指针或是引用），都也愿意接受一个派生类对象（而不管是传指针或是引用）。（只对public继承才成立。）      好的接口可以防止无效的代码通过编译，因此你应该宁可采取“在编译期拒绝”的设计，而不是“运行期才侦测”的设计。      请记住：

• “public继承”意味is-a。适用于base classes身上的每一件事情一定也使用于derived classes身上，因为每一个derived classes对象也都是一个base classes对象。    

    条款33：避免遮掩继承而来的名称     C++的名称遮掩规则所做的唯一事情就是：遮掩名称。至于名称是否是相同或不同的类型，并不重要。即，只要名称相同就覆盖基类相应的成员，不管是类型，参数个数，都无关紧要。派生类的作用域嵌套在基类的作用域内。      C++的继承关系的遮掩名称也并不管成员函数是纯虚函数，非纯虚函数或非虚函数等。只和名称有关。      如果你真的需要用到基类的被名称遮掩的函数，可以使用using声明式，引入基类的成员函数。     请记住：

• derived calsses内的名称会遮掩base classes内的名称。在public继承下从来没有人希望如此。   
• 为了让被遮掩的名称再见天日，可使用using声明式或转交函数（forwarding function）。

    条款34：区分接口继承和实现继承     表面上直截了当的public继承概念，经过更严密的检查之后，发现它由两部分组成：函数接口继承和函数实现继承。

• 成员函数的接口总是会被继承。
• 声明一个纯虚函数的目的是为了让派生类只继承函数接口。
• 声明一个虚函数的目的是让派生类继承该函数的接口和缺省实现。
• 声明一个非虚函数的目的是为了令派生类继承函数的接口及一份强制性实现。

    请记住：

• 接口继承和实现继承不同。在public继承之下，derived classes总是继承base class的接口。
• pure virtual函数只具体制定接口继承。
• 简朴的（非纯）impure virtual函数具体制定接口继承及缺省实现继承。
• non-virtual函数具体制定接口继承以及强制性实现继承。

    条款35：考虑virtual函数以外的其它选择     请记住：

• virtual函数的替代方案包括NVI手法及Strategy设计模式的多种形式。NVI手法自身是一个特殊形式的Template Method设计模式。
• 将机能从成员函数移到class外部函数，带来的一个缺点是，非成员函数无法访问class的non-public成员。
• tr1::function对象的行为就像一般函数指针。这样的对象可接纳“与给定之目标签名式（target signature）兼容”的所有可调用物（callable entities）。   

    条款36：绝不重新定义继承而来的non-virtual函数     请记住：

• 绝对不要重新定义继承而来的non-virtual函数。   

     条款37：绝不重新定义继承而来的缺省参数值     对于non-virtual函数，上一条款说到，“绝不重新定义继承而来的non-virtual函数”，而对于继承一个带有缺省参数值的virtual函数，也是如此。即绝不重新定义继承而来的缺省参数值。因为：virtual函数系动态绑定（dynamically bound），而缺省参数值确实静态绑定（statically bound）。意思是你可能会在“调用一个定义于派生类内的虚函数”的同时，却使用基类为它所指定的缺省参数值。      请记住：

• 绝对不要重新定义一个继承而来的缺省参数值，因为缺省参数值都是静态绑定，而virtual函数——你唯一应该覆写的东西——却是动态绑定。

     条款38：通过符合塑模出has-a或“根据某物实现出”      请记住：

• 复合（composition）的意义和public继承完全不同。
• 在应用域（application domain），复合意味has-a（有一个）。在实现域（implementation domain），复合意味is-implemented-in-terms-of（根据某物实现出）。