Effective C++ 总结(三)

五.实现    
    


    条款26:尽可能延后变量定义式的出现时间

 

  如果你定义了一个变量且该类型带一个构造函数或析构函数,当程序到达该变量时,你要承受构造成本,而离开作用域时,你要承受析构成本。为了减少这个成本,最好尽可能延后变量定义式的出现时间。举例说明:

string encryptPassword(const string& password) 
{
  string encrypted; //(1)
  if (password.length() < MINIMUM_PASSWORD_LENGTH) {
   throw logic_error("Password is too short");
 }
 //进行必要的操作,将口令的加密版本放进encrypted之中;
 
  string encrypted; //(2)
  return encrypted;
}

  encrypted应该在(2)处定义,因为如果在(1)处定义,如果抛出异常,那么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:主要用来执行“安全向下转型”,即:基类指针/引用到派生类指针/引用的转换。如果源和目标类型没有继承/被继承关系,编译器会报错;否则必须在代码里判断返回值是否为NULL来确认转换是否成功。有条件转换,动态类型转换,运行时类型安全检查(转换失败返回NULL)
  reinterpret_cast:意图执行低级转型,将数据从一种类型的转换为另一种类型,也就是说将数据以二进制存在的形式进行重新解释。实际动作可能取决于编译器,这也就表示它不可移植
  static_cast:用来静态类型转换,强制类型转换,运行时不做类型检查,因而可能是不安全的。例如将non-const转型为const,int转型为double等等。 static_cast也可以进行基类和子类之间转换:其中子类指针转换成父类指针是安全的;但父类指针转换成子类指针是不安全的。(基类和子类之间的动态类型转换建议用dynamic_cast)

  upcast:Just same as dynamic_cast. 由于不用做runtime类型检查,效率比dynamic_cast高;

  downcast:不安全。不建议使用。

#include <iostream>  
using namespace std;  
class Base  
{  
public:  
    virtual int foo(){  
        cout<<"Base"<<endl;  
        return 0;  
    };  
};  
  
class Derived:public Base  
{  
public:  
    int foo(){  
        cout<<"Derived"<<endl;  
        return 0;  
    }  
};  
int main()  
{  
    Base *b=new Base;  
    Derived *d1=static_cast<Derived*>(b);  
    d1->foo(); // 正确  
    Derived *d2=dynamic_cast<Derived*>(b);  
    d2->foo(); //错误  
} 

尽量使用新式转型:

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

    请记住:

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

 


 

    条款28:避免返回 handls 指向对象内部成分

class Point  
{  
public:  
    Point(int x, int y);  
    void SetX(int newVal);  
    void SetY(int newVal);  
private:  
    int x_cor;  
    int y_cor;  
};  
  
struct RectData  
{  
    Point ulhc;    // 矩形左上角的点  
    Point lrhc;    // 矩形右下角的点  
};  
class Rectangle  
{  
private:  
    shared_ptr<RectData> pData;  
public:  
    Point& upperLeft()const{ return pData->lrhc; }  
    Point& lowerRight()const{ return pData->ulhc; }  
};  

  上面的代吗中Point是表示坐标系中点的类,RectData表示一个矩形的左上角与右下角点的点坐标。Rectangle是一个矩形的类,包含了一个指向RectData的指针。

我们可以看到了uppLeft和lowerRight是两个const成员函数,它们的功能只是想向客户提供两个Rectangle相关的坐标点,而不是让客户修改Rectangle。但是两个函数却都返回了references指向了private内部数据,调用者于是可以通过references更改内部数据

  这给了我们一些警示:成员变量的封装性只等于“返回其reference”的函数的访问级别;如果const成员函数传出一个reference,后者所指数据与对象自身有关联,而它又被存储于对象之外,那么这个函数的调用者可以修改那笔数据。

  handles(号码牌,用于取得某个对象)指reference、指针和迭代器,它们返回一个“代表对象内部数据”的handle。

  解决方法:我们可以对上面的成员函数返回类型上加上const

public:  
    const Point& upperLeft()const{ return pData->lrhc; }  
    const Point& lowerRight()const{ return pData->ulhc; } 

  但是函数返回一个handle代表对象内部成分还总是危险的,因为可能会造成dangling handles(空悬的号牌)。比如某个函数返回GUI对象的外框(bounding box)。

class GUIObject{  
    //..  
};  
const Rectangle boundingBox(const GUIObject &obj);          
GUIObject* pgo;  
const Point* pUpperLeft = &(boundingBox(*pgo).upperLeft());  

  对boundingBox返回的是一个新的,暂时的Rectangle对象temp,而pUpperLeft指向的是temp的Points。

  当const Point* pUpperLeft = &(boundingBox(*pgo).upperLeft());执行完之后,temp将会被销毁,从而导致temp内的Points析构,最终将导致pUpperLeft 指向一个不存在的对象,从而造成悬空、虚吊。

 请记住:

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

    条款30:透彻了解inlining的里里外外

 

   Inline(内联)函数,多棒的点子!它们看起来像函数,动作像函数,比宏好得多,可以调用它们又不需蒙受函数调用所招致的额外开销。你实际获得的比想象的还多,编译器有能力对执行语境相关最优化。然而编写程序就像现实生活一样,没有白吃的午餐。inline函数也不例外,这样做可能增加你的目标码
  如果 inline 函数的本体很小,编译器针对“函数本体”所产生的码可能比针对“函数调用”所产出的码更小。果真如此,将函数inlining确实可能导致较小的目标码和较高的指令高速缓存装置击中率。
     记住,inline 只是对编译器的一个申请,不是强制命令。这项申请可以隐喻提出,也可以明确提出。隐喻方式是将函数定义于class定义式内,这样的函数通常是成员函数,friend函数也可被定义于class内,如果真是那样,它们也是被隐喻声明为inline。明确声明inline函数的做法则是在其定义式钱加上关键字inline。
     Inline函数通常一定被置于头文件内,因为大多数建置环境(building environment)在编译过程中进行inlining,而为了将一个“函数调用”替换为“被调用函数的本体”,编译器必须知道那个函数长什么样子。
     Template通常也被置于头文件内,因为它一旦被使用,编译器为了将它具现化,需要知道它长什么样子。
     Template的具现化与inlining无关。如果你正在写一个template而你认为所有根据此template具现出来的函数都应该inlined,请将此template声明为inline;但如果你写的template没有理由要求它所具现的每一个函数都是inlined,就应该避免将这个template声明为inline。
     一个表面上看似inline的函数是否真实inline,取决于你的建置环境(building environment),主要取决于编译器。
     有的时候虽然编译器有意愿inlining某个函数,还是可能为该函数生成一个函数本体(函数指针,构造函数,析构函数)。比如,当程序要取某个inline函数的地址,编译器通常必须为此函数生成一个oulined函数本体,因为编译器没有能力让一个指针指向一个并不存在的函数。

inline void f(){..}   
void (*pf)()=f;  
..  
f();  //这个将被inline  
pf(); //这个或许不被inline,因为它通过函数指针完成

  对程序开发而言,将上述所有考虑牢记在新很是重要,但若从纯粹实用观点出发,有一个事实比其它因素更重要:大部分调试器面对inline函数都束手无策。
  这使我们在决定哪些函数该被声明为inline而哪些函数不该时,掌握一个合乎逻辑的策略。一开始先不要将任何函数声明为inline,或至少将inlining施行范围局限在那些“一定成为inline”或“十分平淡无奇”的函数身上。

 

总结:

1. inline函数的调用,是对函数本体的调用,是函数的展开,使用不当会造成代码膨胀。

2. 大多数C++程序的inline函数都放在头文件,inlining发生在编译期。

3. inline函数只代表“函数本体”,并没有“函数实质”,是没有函数地址的(内联优化从目标文件中去掉了该函数的入口点,符号表中也没有该函数的名称)。

4. inlining在大多数编译器中编译期行为, inline 函数无法随着程序库的升级而升级。换句话说如果f 是程序库内的一个inline 函数,客户将”f 函数本体”编进其程序中,一旦程序库设计者决定改变f ,所有用到f 的客户端程序都必须重新编译。但如果f是non-inline函数,当修改f后,客户端只需要重新连接就好了。

 

值得注意的是:

1. 构造函数与析构函数往往不适合inline。因为这两个函数都包含了很多隐式的调用,而这些调用付出的代价是值得考虑的。可能会有代码膨胀的情况。

2. inline函数无法随着程序库升级而升级。因为大多数都发生在编译期,升级意味着重新编译。

3. 大部分调试器(VS2010可以)是不能在inline函数设断点的。因为inline函数没有地址。

 

     请记住:

  • 将大多数inlining限制在小型、被频繁调用的函数身上。这可使日后的调试过程和二进制升级更容易,也可使潜在的代码膨胀问题最小化,是程序的速度提升机会最大化。
  • 另外,对function templates的inline也要慎重,保证其所有实现的函数都应该inlined后再加inline。   

 


 

     条款31:将文件间的编译依存关系降至最低

 

  这个问题产生是源于希望编译时影响的范围尽量小,编译效率更高,维护成本更低,这一需求。

  实现这个目标首先第一个想到的就是,声明与定义的分离,用户的使用只依赖声明,而不依赖定义(也就是具体实现)。

  但C++的Class的定义式却不仅仅只有接口,还有实现细目(这里指实现接口需要的私有成员)。而有时候我们需要修改的通常是接口的实现方法,而这一修改可能需要添加私有变量,但这个私有变量对用户是不应该可见的。但这一修改却放在了定义式的头文件中,从而造成了,使用这一头文件的所有代码的重新编译。

  于是就有了pimpl(pointer to implementation)的方法。用pimpl把实现细节隐藏起来,在头文件中只需要一个声明就可以,而这个poniter则作为private成员变量供调用。

  这里会有个有意思的地方,为什么用的是指针,而不是具体对象呢?这就要问编译器了,因为编译器在定义变量时是需要预先知道变量的空间大小的,而如果只给一个声明而没有定义的话是不知道大小的,而指针的大小是固定的,所以可以定义指针(即使只提供了一个声明)。

  这样把实现细节隐藏了,那么实现方法的改变就不会引起别的部分代码的重新编译了。而且头文件中只提供了impl类的声明,而基本的实现都不会让用户看见,也增加了封装性。

  结构应该如下:

class PersonImpl;  
class Person {  
public:  
    ...  
private:  
    std::tr1::shared_ptr<PersonImpl> PersonImpl;  
};  

  这一种类也叫handle class

  另一种实现方法就是用带factory函数的interface class。就是把接口都写成纯虚的,实现都在子类中,通过factory函数或者是virtual构造函数来产生实例。

  声明文件时这么写:

class Person  
{  
public:  
    static shared_ptr<Person> create(const string&,  
        const Data&,  
        const Adress&);  
}; 

  定义实现的文件这么写

class RealPerson :public Person  
{  
public:  
    RealPerson(...);  
    virtual ~RealPerson(){}  
    //...  
private:  
    // ...  
};  

  有了RealPerson之后,就可以写出Person::create函数了:

std::tr1::shared_ptr<Person> Person::create(const string& name  
                                            const Data& birthday  
        <span style="white-space:pre">            </span>    const Address& adrr)  
{  
    return std::tr1::shared_ptr<Person>(new RealPerson(name,birthday,addr));  
}  

请记住:

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

六.继承与面向对象设计
  

    条款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++的名称遮掩规则所做的唯一事情就是:遮掩名称。只要Derived class有和base class中相同的函数名,不管其返回值,参数类型,参数个数是否相同,也不管成员函数是纯虚函数,非纯虚函数或非虚函数。只要名称相同就发生覆盖。派生类的作用域嵌套在基类的作用域内。
     (1)derived classes内的名称会遮掩base classes内的名称(即使变量的类型不同,或者函数的参数不同)。如下面代码所示:

class Base {  
 private:  
  int x;  
 public:  
  virtual void mfl() = 0;  
  virtual void mfl(int);  
  virtual void mf2();  
  void mf3 ();  
  void mf3(double);  
};  
   
class Derived: public Base {  
 public:  
  virtual void mfl();  
  void mf3 ();  
  void mf4 ();  
  …  
};  
  
Derived d;  
int x;  
  
d.mfl();   //正确,调用Derived::mfl  
d.mfl(x);  //错误,名称被覆盖  
d.mf2();   //正确,调用Base::mf2  
d.mf3();   //正确,调用Derived::mf3  
d.mf3(x);  //错去,名称被覆盖</span>  

  (2) 为了让被遮掩的名称再见天日,可使用using 声明式或转交函数( forwarding functions) 。

 

  (a) 使用using声明式

class Base {  
 private:  
  int x;  
 public:  
  virtual void mfl() = 0;  
  virtual void mfl(int);  
  virtual void mf2();  
  void mf3 ();  
}  
   
void mf3(double); class Derived: public Base {  
 public:  
  using Base::mfl; //使用using 声明式  
  using Base: :mf3; //使用using 声明式  
  virtual void mfl();  
  void mf3 ();  
  void mf4();  
}  
   
Derived d  
int x;  
d.mf1 () ; //仍调用Derived: :mfl  
d.mf1 (x); //调用Base: :mfl  
d.mf2 () ; //调用Base: :mf2  
d.mf3 ();//调用Derived: :mf3  
d.mf3 (x); //调用Base: :mf3</span> 

  (b) 使用转交函数

class Derived: private Base (  
 public:  
  virtual void mfl () //转变函数(forwading  function) ,  
  { Base:: mfl ( );} //暗自成为inline  
}  
Derived d;  
int x;  
d.mfl();    //正确,调用Derived::mfl  
d.mfl(x);   //错误,名称被遮掩

请记住:

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


    条款34:区分接口继承和实现继承

  本条款主要讲函数接口继承(也就是声明)和函数实现继承,以及pure virtual 函数、simple(impure) virtual 、non-virtual函数之间的差异。
(1)接口继承和实现继承不同。在public 继承之下, derived classes 总是继承base class的接口。
(2) pure virtual 函数只具体指定接口继承。(要求继承者必须重新实现该接口)
(3) 简朴的(非纯) impure virtual 函数具体指定接口继承及缺省实现继承(继承者可自己实现该接口也可使用缺省实现)。
(4) non-virtual 函数具体指定接口继承以及强制性实现继承。(继承者必须使用该接口的实现)
class Shape {  
 public:  
  virtual void draw( ) const = 0; //pure virtual 函数  
  virtual void error(const std::string& msg); //简朴的(非纯) impure virtual 函数  
  int objectID ( ) const;// non-virtual 函数  
};  

请记住:

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

    条款35:考虑virtual函数以外的其它选择

   

  本条款告诉程序员,当需要使用virtual 函数时,可以考虑其他选择。

  Virtual函数的替代方案是:
  (1) 使用non-virtual interface(NVI)手法。思想是:将virutal函数放在private中,而在public中使用一个non-virtual函数调用该virtual函数。优点是:可以做一些预处理、后处理工作。

class GameCharacter {  
 public:  
  int healthValue() const{             // 1. 子类不能重定义  
    ...                               // 2. preprocess  
    int retVal = doHealthValue();     // 2. 真正的工作放到虚函数中  
    ...                               // 2. postprocess  
   return retVal;  
  }  
 private:  
  virtual int doHealthValue() const {   // 3. 子类可重定义  
    ...  
   }  
};  

  例如:

class Base {  
public:  
    Base(int i):val(i){};  
  
    int healthValue() const  
    {                                              
        int retVal = doHealthValue();  
        return retVal;  
    }  
private:  
    virtual int doHealthValue() const   
    {             
        return val;  
    }  
      
    int val;  
};  
class Derived: public Base {  
public:  
    Derived(int i,int j):Base(i),val(j){};  
private:  
    virtual int doHealthValue() const   
    {  
        return val;  
    }  
    int val;  
};  
  
int main()  
{  
    Derived d(1,2);  
    cout<<d.healthValue()<<endl;  
    return 0;  
}  
  输出:2

  (2)将virtual函数替换为“函数指针成员变量”(这是Strategy设计模式中的一种表现形式),见下面代码。优点是每个对象拥有自己的函数实现,也可在运行时改变计算函数;缺点是:该函数不能访问类中的私有成员(若要访问,必须由公有成员提供接口)
class GameCharacter;  
int defaultHealthCalc(const GameCharacter& gc); // default algorithm  
class GameCharacter {  
public:  
 typedef int (*HealthCalcFunc)(const GameCharacter&);  
 explicit GameCharacter(HealthCalcFunc hcf = defaultHealthCalc)  
  : healthFunc(hcf)  
 { }  
 int healthValue() const {  
  return healthFunc(*this);  
 }  
 ...  
private:  
 HealthCalcFunc healthFunc;  
};  
  (3) 以tr1::function成员变量替换virtual函数,这允许使用任何可调用物搭配一个兼容于需求的签名式。这也是Strategy设计模式的某种形式。这种方式比上面的函数指针更灵活、限制更少:
    [1]返回值不一定是int,与其兼容即可; 
    [2]可以是function对象; 
    [3]可以是类的成员函数。
  
  (4) 继承体系内的virtual函数替换为另一个继承体系内的virtual函数。这是Strategy设计模式的传统实现手法。这种方式最大的优点是:可以随时添加新的算法。举例:
class GameCharacter;  
   
class HealthCalcFunc {  
   
 public:  
   
  ...  
   
  virtual int calc(const GameCharacter& gc) const  
   
   { ... }  
   
  ...  
   
};  
   
HealthCalcFunc defaultHealthCalc;  
   
class GameCharacter {  
   
 public:  
   
  explicit GameCharacter(HealthCalcFunc *phcf = &defaultHealthCalc)  
   
   : pHealthCalc(phcf)  
   
    {}  
   
  int healthValue() const {  
   
   return pHealthCalc->calc(*this);  
   
 }  
   
  ...  
   
private:  
   
HealthCalcFunc *pHealthCalc;  
   
};  

 


   条款36:绝不重新定义继承而来的non-virtual函数

//类的定义  
class B{  
public:  
        void func(){ cout<<“B”;}  
 virtual void func2(){ cout<<“B”;}  
};  
  
class D:public B{  
publicvoid func() { cout<<“D”;}  
 virtual void func2(){ cout<<“D”;}  
};  
  
//下面是对B和D的使用  
D dObject;  
B* bPtr = &dObject;  
D* dPtr = &dObject;  
  
//下面这两种调用方式:  
bPtr->func();  //调用B::func  
dPtr->func();  //调用D::func  
bPtr->func2();  //调用D::func  
dPtr->func2();  //调用D::func 
  解释:在C++继承中,virtual函数是动态绑定的,调用的函数跟指针或者引用实际绑定的对象有关,而non-virtual函数是静态绑定的,调用的函数只跟声明的指针或者引用的类型相关。
 
  • 不要重新定义继承而来的non-virtual函数。   

     条款37:绝不重新定义继承而来的缺省参数值


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

class Shape{  
   
 public:  
   
  enum Color{RED,GREEN,BLUE};  
   
  virtual void draw(Color color = RED)const = 0;  
   
  ...  
   
};  
   
class Circle:public Shape{  
   
 public:  
   
  //竟然改变缺省参数值  
   
  virtual void draw(Color color = GREEN)const{ ... }  
   
};  
   
Shape* pc = new Circle; //静态绑定为RED  
pc->draw(); //注意调用的是: Circle::draw(RED),也就是说,此处的draw函数是基类和派生类的“混合物”  
Circle* pc = new Circle; //静态绑定为GREEN  

  为什么缺省参数是静态绑定而不是动态绑定呢?主要原因是运行效率。如果缺省参数采用动态绑定,那么编译器就必须有某种方法在运行期为virtual函数决定适当的缺省参数,这样会使程序的执行效率低下并且实现机理更加复杂。

  聪明的做法是考虑替代设计,如条款35中的一些virutal函数的替代设计,其中之一是NVI手法,令base class内的一个public non-virtual函数调用private virtual函数。

class Shape  
{  
public:  
    enum ShapeColor{ Red, Green, Blue };  
    virtual void draw(ShapeColor color = Red)const  
    {  
        doDraw(color);  
    }  
private:  
    virtual void doDraw(ShapeColor color)const = 0;  
};  
class Rectangle :public Shape  
{  
private:  
    virtual void doDraw(ShapeColor color)const;  
};  

请记住:

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

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

 

  复合或包含意味着has-a。如果我们想设计一个自己的set,我们思考后觉得可以用list来实现它,但是如果我把它设计出list的一个派生类,就会有问题,因为父类的所有行为在派生类都是被允许的,而list允许元素重复,而set则显然不行,所以set与list之间不符合is-a关系,我们可以把list设计为set的一个成员,即包含关系(has-a)。

 

 


    条款39:通过符合塑模出has-a或“根据某物实现出”

 

   明智而审慎地使用private继承
  (1)如果class之间的继承关系是private。编译器不会自动将一个derived class对象转化为一个base class对象。由private base class继承而来的所有成员,在derived class中都会变成private属性,纵使它们在base class中原来是protected或public属性。

class Person {..}  
class Student:private Person{..}  
  
void eat(const Person&);  
Person p;  
Student s;  
  
eat(p);  //正确  
eat(s);  //错误  

  (2)private继承“并不存在is-a关系”的classes,而是has-a或is-implemented-in-terms-of的继承模型。如果我们只想利用base class的一部分功能,而又不想把base class暴露给其他外部对象使用,可以使用private继承。

 

      主要有三种使用场合:

      (a)其中一个derived class 需要访问base class的protected成员;

      (b)derived class 需要重新定义base class中一个或多个virtual函数。

      (c)需要对empty classes的空间最优化,如下面的代码:

class Empty{ }; //empty class  
class HoldsAnyInt{  
private:  
 int x;  
 Empty e;  
};//sizeof(HoldsAnyInt) =8。//对于大小为0的独立对象,通常C++会在对象内需要安插一个char, 并且有位对齐要求。  
  
class HoldsAnyInt::private Empty{  
private:  
 int x;  
}; //sizeof(HoldsAnyInt) == sizeof(int),这个就是EBO(empty based optimization 空白基类优化)。

 


 

 条款40:明智而审慎地使用多重继承

 

  使用多重继承就要考虑歧义的问题(成员变量或者成员函数的重名)。最简单的情况的解决方案是显式的调用(诸如item.Base::f()的形式)。

  复杂一点的,就可能会出现“钻石型多重继承”,以File为例:

class File { ... }  
class InputFile : public File { ... }  
class OutputFile : public File { ... }  
class IOFile : public InputFile, public OutputFile { ... }  

  这里的问题是,当File有个filename时,InputFile与OutputFile都是有的,那么IOFile继承后就会复制两次,就有两个filename,这在逻辑上是不合适的。解决方案就是用virtual继承:

class File { ... }  
class InputFile : virtual public File { ... }  
class OutputFile : virtual public File { ... }  
class IOFile : public InputFile, public OutputFile { ... }  
  这样InputFile与OutputFile共享的数据就会在IOFile中只保留一份了。

  但是virtual继承并不常用,因为:

  1. virtual继承会增加空间与时间的成本。

  2. virtual继承会非常复杂(编写成本),因为无论是间接还是直接地继承到的virtual base class都必须承担这些bases的初始化工作,无论是多少层的继承都是。

posted @ 2015-02-05 19:38  wiessharling  阅读(237)  评论(0编辑  收藏  举报