sherrylso

四、c++中的多態(tài)規(guī)則。
一） c++中函數(shù)動(dòng)態(tài)綁定規(guī)則。
看下面的例子：

class Window
{

public:
  virtual void  oops()
  {
    cout<<"Window oops"<<endl;
  }
public:
  int height;
  int width;
};
class TextWindow : public Window
{

public:
  virtual void  oops()
  {
    cout<<"TextWindow oops"<<cursorLocation<<endl;
  }
public:
  int cursorLocation;
};

main()
{
  Window win;
  Window* tWin;
  TextWindow * tWinPtr;

  tWinPtr = new TextWindow;
  tWin = tWinPtr;
  
  win.oops();
  tWin->oops();
}

類TextWindow繼承與類Window。我想程序運(yùn)行的結(jié)果，大多數(shù)熟悉C++的人都會(huì)知道，
win.oops()最終調(diào)用的是父類oops函數(shù)，而tWin->oops()調(diào)用的是子類TextWindow的函數(shù)。
通過(guò)這個(gè)例子，我們先總結(jié)一下c++中的多態(tài)調(diào)用規(guī)則：
第一、對(duì)于指針和引用類型，當(dāng)消息調(diào)用的成員函數(shù)有可能被重寫時(shí)，最終被選擇調(diào)用的成員函數(shù)由消息接收者的動(dòng)態(tài)類型確定(注意：在OO概念中，對(duì)某個(gè)對(duì)象成員函數(shù)進(jìn)行調(diào)用，常常稱為給該對(duì)象發(fā)送消息，該對(duì)象就是消息的接收者）。
      如上例：tWin->oops(),由于tWin的動(dòng)態(tài)類型是子類TextWindow,而不是Windows,所以tWin->oops()調(diào)用的是子類TextWindow的函數(shù)。
第二、對(duì)于其它的變量，對(duì)虛擬函數(shù)調(diào)用綁定完全由該變量的靜態(tài)類型確定（即該變量的聲明），而不是該變量的真實(shí)類型確定。
     如上例：win.oops(),由于win的聲明類型為Window類,所以其結(jié)果調(diào)用的是父類oops函數(shù)。
二） 探討。
     接下來(lái)，我們要看的問(wèn)題是，在c++中，為什么對(duì)于多態(tài)規(guī)則(或者說(shuō)是動(dòng)態(tài)函數(shù)綁定規(guī)則)，做出了兩中不同的劃分，即：只有指針與引用類型，才進(jìn)行函數(shù)的后期動(dòng)態(tài)綁定，也就是多態(tài)。這或許也是許多c++初學(xué)者非常迷惑的地方。這種規(guī)則的不一致性，的確給c++的語(yǔ)法造成一定的復(fù)雜性。而這在Java，或者C#中是沒(méi)有的，后面我們會(huì)涉及到。
      我們先來(lái)看例子。 

void f()
{
  Window  win;
  Window* tWinPtr;
  
  tWinPtr = new TextWindow;
  win     = *tWinPtr;//what's problem happen
   
  win.oops(); //what's problem happen
  tWinPtr->oops();
}

      在這里,如果我們假設(shè)，c++的函數(shù)動(dòng)態(tài)綁定規(guī)則是一致的，看看會(huì)發(fā)生什么問(wèn)題???
      現(xiàn)在win被聲明為Window類型，然而其真實(shí)的類型為TextWindow(因?yàn)閣in=*tWinPtr),由于我們的假設(shè)，win現(xiàn)在是允許進(jìn)行動(dòng)態(tài)函數(shù)綁定的，所以當(dāng)執(zhí)行win.oops()時(shí)，實(shí)際上是調(diào)用子類TextWindow的成員函數(shù)。
     現(xiàn)在，我們有必要來(lái)審視一下win變量的內(nèi)存布局。由于win變量是在棧上聲明的變量，其內(nèi)存也是從棧進(jìn)行分配（這是c++從c語(yǔ)言那里繼承過(guò)來(lái)的優(yōu)良特質(zhì)，從棧上分配內(nèi)存空間比動(dòng)態(tài)分配內(nèi)存有更好的執(zhí)行速度），c++標(biāo)準(zhǔn)規(guī)定：給win變量分配內(nèi)存空間的大小，由其靜態(tài)的類型確定，即應(yīng)該是Window類所使用的內(nèi)存空間大小。在這種情況下，當(dāng)執(zhí)行win=*tWinPtr時(shí)，什么會(huì)發(fā)生？如下圖：

在默認(rèn)的拷貝構(gòu)造函數(shù)情況下，信息會(huì)出現(xiàn)丟失，這就是著名的slicing off現(xiàn)象。結(jié)果，變量cursorLocation在win的內(nèi)存空間里丟失了。然而，問(wèn)題是：在我們假設(shè)下，我們要求win.oops()導(dǎo)致TextWindow的成員函數(shù)調(diào)用，而在這個(gè)函數(shù)中，訪問(wèn)到的cursorLocation變量是不存在！win.oops()調(diào)用將導(dǎo)致內(nèi)存違例！
      到這里，我們可以總結(jié)一下：c++標(biāo)準(zhǔn)基于的其特定的內(nèi)存分配規(guī)則，給出了以上，我們?cè)谇耙还?jié)總結(jié)出的函數(shù)動(dòng)態(tài)綁定規(guī)則。
三） 深入。
      當(dāng)然，我們也可以說(shuō)，c++也可以通過(guò)改變其內(nèi)存分配規(guī)則，來(lái)給出一個(gè)一致性的函數(shù)動(dòng)態(tài)綁定規(guī)則。比如：可以考慮在給win變量分配內(nèi)存空間時(shí)，考慮其所有子類需求，然后分配最大數(shù)量的內(nèi)存空間給win變量。這種做法可行性很差，對(duì)于編譯器而言，需要掃描整個(gè)程序(確定該類的所有子類)，才能確定最大的內(nèi)存空間是多少。在使用類庫(kù)或者框架的情況下，會(huì)引起整個(gè)類庫(kù)，框架的重新編譯，這是得不償失的！而這種做法，在oo的語(yǔ)言中，基本上是沒(méi)有的。這也是c++不得不基于其現(xiàn)有的內(nèi)存管理機(jī)制，而對(duì)多態(tài)規(guī)則作出的不一致的解釋。
    對(duì)于這個(gè)c++現(xiàn)有的內(nèi)存管理機(jī)制,我們?nèi)绻麖牧硗饨嵌热ダ斫獾脑?是很合理的。當(dāng)win=*tWinPtr發(fā)生
時(shí)，我們可以類似地認(rèn)為：好比一個(gè)float類型的數(shù)賦給了一個(gè)interger類型的變量，其結(jié)果當(dāng)然是float的值被截?cái)嗔恕?br>    我們?cè)賮?lái)看其它語(yǔ)言，Java（或者C#）是怎么解決的。
    最重要的一點(diǎn)是，在Java(C#)中只有引用的概念，所以在棧上聲明的類的變量，只需要分配一個(gè)指針大小的內(nèi)存空間就行了，而不需要給該變量分配空間來(lái)保存變量?jī)?nèi)容本身，這其實(shí)就是我們現(xiàn)在看到的c++中指針和引用的情況。