C++記憶體分佈 虛表 虛指標：
class Base
{
public:
int m_base;
};

class DerivedA: public Base
{
public:
int m_derivedA;
};

class DerivedB: public Base
{
public:
int m_derivedB;
};

class DerivedC: public DerivedA, public DerivedB
{
public:
int m_derivedC;
};

類結構圖：

記憶體分佈圖：

DerivedC:
DerivedA::m_base
m_derivedA
DerivedB::m_base
m_derivedB
m_derivedC

====================================================
如果DerivedB 和 DerivedC 都是虛繼承 ， 即 virtual public Base
這時記憶體佈局：

DerivedC：
objDerivedA::vbptr
objDerivedA::m_derivedA
objDerivedB::vbptr
objDerivedB::m_derivedB
m_derivedC
m_base 只有一份

類似於這個：

Base, DerivedA, DerivedB 各增加一個虛擬函式
則記憶體佈局為：

DerivedB：
DerivedB::vfptr
DerivedB::vbptr
DerivedB::m_derivedB
Base::vfptr
Base::m_base

DerivedC:
DerivedA::vfptr 04
DerivedA::vbptr 08
DevivedA::m_derivedA 0C
DevivedB::vfptr 10
DerivedB::vbptr 14
DerivedB::m_derivedB 18
m_derivedC 1C
Base::vfptr 20
m_base 24

如果是這樣呢？
class A{}
class B1: classA{virtual fun()}
class B2: virtual public classA{virtual fun()}
class C: public B1,public B2{} 這樣Virtual繼承起不到作用， C還是有兩個內嵌A物件，就是有兩個m_base

Class C:
DerivedA::vfptr
DerivedA::m_base
DerivedA::m_derivedA
DerivedB::vfptr
DerivedB::vbptr
DerivedB::m_derivedB
m_derivedC
DerivedB::m_base
總結：
先基類元素後繼承類元素
有虛擬函式只是增加vfptr；繼承的類如果有增加虛擬函式，向vtable增加函式指標
虛繼承增加vbptr，注意：虛基類元素排在最後（這個是和 先基類後繼承 不同之處）
注意上面，凡是打上了vbptr的類， DerivedB::m_base都被打到了最後。
vfptr在vbptr之前

某人總結—————

單繼承
1.普通繼承+父類無virtual函式
若子類沒有新定義virtual函式 此時子類的佈局是 :
低地址 -> 高地址
父類的元素(沒有vfptr),子類的元素(沒有vfptr).
若子類有新定義virtual函式 此時子類的佈局是 :
低地址 -> 高地址
vfptr,指向vtable, 父類的元素(沒有vfptr), 子類的元素

1. 普通繼承+父類有virtual函式
   不管子類沒有新定義virtual函式 此時子類的佈局是 :
   低地址 -> 高地址
   父類的元素(包含vfptr), 子類的元素.
   如果子類有新定義的virtual函式,那麼在父類的vfptr(也就是第一個vptr)對應的vtable中新增一個函式指標.

3.virtual繼承
若子類沒有新定義virtual函式 此時子類的佈局是 :
低地址 -> 高地址
子類的元素(有vbptr), 虛基類的元素.
為什麼這裡會出現vbptr,因為虛基類派生出來的類中,虛基類的物件不在固定位置(猜測應該是在記憶體的尾部),需 要一箇中介才能訪問虛基類的物件.所以雖然沒有virtual函式,子類也需要有一個vbptr,對應的vtable中需要有一項指向 虛基類.
若子類有新定義virtual函式 此時子類的佈局是與沒有定義新virtual函式記憶體佈局一致.但是在vtable中會多出新增的虛擬函式的指標.

Vbptr是做什麼用的呢？看下面
該變數指向一個全類共享的偏移量表
附：轉一篇文章

——談VC++物件模型
（美）簡 • 格雷
程化 譯
譯者前言
一個C++程式設計師，想要進一步提升技術水平的話，應該多瞭解一些語言的語意細節。對於使用VC++的程式設計師來說，還應該瞭解一些VC++對於C++的詮釋。Inside the C++ Object Model雖然是一本好書，然而，書的篇幅多一些，又和具體的VC++關係小一些。因此，從篇幅和內容來看，譯者認為本文是深入理解C++物件模型比較好的一個出發點。
這篇文章以前看到時就覺得很好，舊文重讀，感覺理解得更多一些了，於是產生了翻譯出來，與大家共享的想法。雖然文章不長，但時間有限，又若干次在翻譯時打盹睡著，拖拖拉拉用了小一個月。
一方面因本人水平所限，另一方面因翻譯時經常打盹，錯誤之處恐怕不少，歡迎大家批評指正。
本文原文出處為MSDN。如果你安裝了MSDN，可以搜尋到C++ Under the Hood。否則也可在網站上找到 http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarvc/html/jangrayhood.asp 。
1 前言
瞭解你所使用的程式語言究竟是如何實現的，對於C++程式設計師可能特別有意義。首先，它可以去除我們對於所使用語言的神祕感，使我們不至於對於編譯器乾的活感到完全不可思議；尤其重要的是，它使我們在Debug和使用語言高階特性的時候，有更多的把握。當需要提高程式碼效率的時候，這些知識也能夠很好地幫助我們。
本文著重回答這樣一些問題：
• * 類如何佈局？
• * 成員變數如何訪問？
• * 成員函式如何訪問？
• * 所謂的“調整塊”（adjuster thunk）是怎麼回事？
• * 使用如下機制時，開銷如何：
• * 單繼承、多重繼承、虛繼承
• * 虛擬函式呼叫
• * 強制轉換到基類，或者強制轉換到虛基類
• * 異常處理
首先，我們順次考察C相容的結構（struct）的佈局，單繼承，多重繼承，以及虛繼承；
接著，我們講成員變數和成員函式的訪問，當然，這裡麵包含虛擬函式的情況；
再接下來，我們考察建構函式，解構函式，以及特殊的賦值操作符成員函式是如何工作的，陣列是如何動態構造和銷燬的；
最後，簡單地介紹對異常處理的支援。
對每個語言特性，我們將簡要介紹該特性背後的動機，該特性自身的語意（當然，本文決不是“C++入門”，大家對此要有充分認識），以及該特性在微軟的VC++中是如何實現的。這裡要注意區分抽象的C++語言語意與其特定實現。微軟之外的其他C++廠商可能提供一個完全不同的實現，我們偶爾也會將VC++的實現與其他實現進行比較。
2 類佈局
本節討論不同的繼承方式造成的不同記憶體佈局。
2.1 C結構（struct）
由於C++基於C，所以C++也“基本上”相容C。特別地，C++規範在“結構”上使用了和C相同的，簡單的記憶體佈局原則：成員變數按其被宣告的順序排列，按具體實現所規定的對齊原則在記憶體地址上對齊。所有的C/C++廠商都保證他們的C/C++編譯器對於有效的C結構採用完全相同的佈局。這裡，A是一個簡單的C結構，其成員佈局和對齊方式都一目瞭然

struct A {
char c;
int i;
};
譯者注：從上圖可見，A在記憶體中佔有8個位元組，按照宣告成員的順序，前4個位元組包含一個字元（實際佔用1個位元組，3個位元組空著，補對齊），後4個位元組包含一個整數。A的指標就指向字元開始位元組處。
2.2 有C++特徵的C結構
當然了，C++不是複雜的C，C++本質上是面向物件的語言：包含繼承、封裝，以及多型。原始的C結構經過改造，成了面向物件世界的基石——類。除了成員變數外，C++類還可以封裝成員函式和其他東西。然而，有趣的是，除非為了實現虛擬函式和虛繼承引入的隱藏成員變數外，C++類例項的大小完全取決於一個類及其基類的成員變數！成員函式基本上不影響類例項的大小。
這裡提供的B是一個C結構，然而，該結構有一些C++特徵：控制成員可見性的“public/protected/private”關鍵字、成員函式、靜態成員，以及巢狀的型別宣告。雖然看著琳琅滿目，實際上只有成員變數才佔用類例項的空間。要注意的是，C++標準委員會不限制由“public/protected/private”關鍵字分開的各段在實現時的先後順序，因此，不同的編譯器實現的記憶體佈局可能並不相同。（在VC++中，成員變數總是按照宣告時的順序排列）。

struct B {
public:
int bm1;
protected:
int bm2;
private:
int bm3;
static int bsm;
void bf();
static void bsf();
typedef void* bpv;
struct N { };
};
譯者注：B中，為何static int bsm不佔用記憶體空間？因為它是靜態成員，該資料存放在程式的資料段中，不在類例項中。
2.3 單繼承
C++提供繼承的目的是在不同的型別之間提取共性。比如，科學家對物種進行分類，從而有種、屬、綱等說法。有了這種層次結構，我們才可能將某些具備特定性質的東西歸入到最合適的分類層次上，如“懷孩子的是哺乳動物”。由於這些屬性可以被子類繼承，所以，我們只要知道“鯨魚、人”是哺乳動物，就可以方便地指出“鯨魚、人都可以懷孩子”。那些特例，如鴨嘴獸（生蛋的哺乳動物），則要求我們對預設的屬性或行為進行覆蓋。
C++中的繼承語法很簡單，在子類後加上“:base”就可以了。下面的D繼承自基類C。

struct C {
int c1;
void cf();
};

struct D : C {
int d1;
void df();
};
既然派生類要保留基類的所有屬性和行為，自然地，每個派生類的例項都包含了一份完整的基類例項資料。在D中，並不是說基類C的資料一定要放在D的資料之前，只不過這樣放的話，能夠保證D中的C物件地址，恰好是D物件地址的第一個位元組。這種安排之下，有了派生類D的指標，要獲得基類C的指標，就不必要計算偏移量了。幾乎所有知名的C++廠商都採用這種記憶體安排（基類成員在前）。在單繼承類層次下，每一個新的派生類都簡單地把自己的成員變數新增到基類的成員變數之後。看看上圖，C物件指標和D物件指標指向同一地址。
2.4 多重繼承
大多數情況下，其實單繼承就足夠了。但是，C++為了我們的方便，還提供了多重繼承。
比如，我們有一個組織模型，其中有經理類（分任務），工人類（幹活）。那麼，對於一線經理類，即既要從上級經理那裡領取任務幹活，又要向下級工人分任務的角色來說，如何在類層次中表達呢？單繼承在此就有點力不勝任。我們可以安排經理類先繼承工人類，一線經理類再繼承經理類，但這種層次結構錯誤地讓經理類繼承了工人類的屬性和行為。反之亦然。當然，一線經理類也可以僅僅從一個類（經理類或工人類）繼承，或者一個都不繼承，重新宣告一個或兩個介面，但這樣的實現弊處太多：多型不可能了；未能重用現有的介面；最嚴重的是，當介面變化時，必須多處維護。最合理的情況似乎是一線經理從兩個地方繼承屬性和行為——經理類、工人類。
C++就允許用多重繼承來解決這樣的問題：
struct Manager … { … };
struct Worker … { … };
struct MiddleManager : Manager, Worker { … };
這樣的繼承將造成怎樣的類佈局呢？下面我們還是用“字母類”來舉例：

struct E {
int e1;
void ef();
};

struct F : C, E {
int f1;
void ff();
};
結構F從C和E多重繼承得來。與單繼承相同的是，F例項拷貝了每個基類的所有資料。與單繼承不同的是，在多重繼承下，內嵌的兩個基類的物件指標不可能全都與派生類物件指標相同：
F f;
// (void*)&f == (void*)(C*)&f;
// (void*)&f < (void*)(E*)&f;
譯者注：上面那行說明C物件指標與F物件指標相同，下面那行說明E物件指標與F物件指標不同。
觀察類佈局，可以看到F中內嵌的E物件，其指標與F指標並不相同。正如後文討論強制轉化和成員函式時指出的，這個偏移量會造成少量的呼叫開銷。
具體的編譯器實現可以自由地選擇內嵌基類和派生類的佈局。VC++按照基類的宣告順序先排列基類例項資料，最後才排列派生類資料。當然，派生類資料本身也是按照宣告順序佈局的（本規則並非一成不變，我們會看到，當一些基類有虛擬函式而另一些基類沒有時，記憶體佈局並非如此）。
2.5 虛繼承
回到我們討論的一線經理類例子。讓我們考慮這種情況：如果經理類和工人類都繼承自“僱員類”，將會發生什麼？
struct Employee { … };
struct Manager : Employee { … };
struct Worker : Employee { … };
struct MiddleManager : Manager, Worker { … };
如果經理類和工人類都繼承自僱員類，很自然地，它們每個類都會從僱員類獲得一份資料拷貝。如果不作特殊處理，一線經理類的例項將含有兩個僱員類例項，它們分別來自兩個僱員基類。如果僱員類成員變數不多，問題不嚴重；如果成員變數眾多，則那份多餘的拷貝將造成例項生成時的嚴重開銷。更糟的是，這兩份不同的僱員例項可能分別被修改，造成資料的不一致。因此，我們需要讓經理類和工人類進行特殊的宣告，說明它們願意共享一份僱員基類例項資料。
很不幸，在C++中，這種“共享繼承”被稱為“虛繼承”，把問題搞得似乎很抽象。虛繼承的語法很簡單，在指定基類時加上virtual關鍵字即可。
struct Employee { … };
struct Manager : virtual Employee { … };
struct Worker : virtual Employee { … };
struct MiddleManager : Manager, Worker { … };
使用虛繼承，比起單繼承和多重繼承有更大的實現開銷、呼叫開銷。回憶一下，在單繼承和多重繼承的情況下，內嵌的基類例項地址比起派生類例項地址來，要麼地址相同（單繼承，以及多重繼承的最靠左基類），要麼地址相差一個固定偏移量（多重繼承的非最靠左基類）。然而，當虛繼承時，一般說來，派生類地址和其虛基類地址之間的偏移量是不固定的，因為如果這個派生類又被進一步繼承的話，最終派生類會把共享的虛基類例項資料放到一個與上一層派生類不同的偏移量處。請看下例：

struct G : virtual C {
int g1;
void gf();
};
譯者注：GdGvbptrG（In G, the displacement of G’s virtual base pointer to G）意思是：在G中，G物件的指標與G的虛基類表指標之間的偏移量，在此可見為0，因為G物件記憶體佈局第一項就是虛基類表指標； GdGvbptrC（In G, the displacement of G’s virtual base pointer to C）意思是：在G中，C物件的指標與G的虛基類表指標之間的偏移量，在此可見為8。

struct H : virtual C {
int h1;
void hf();
};

struct I : G, H {
int i1;
void _if();
};
暫時不追究vbptr成員變數從何而來。從上面這些圖可以直觀地看到，在G物件中，內嵌的C基類物件的資料緊跟在G的資料之後，在H物件中，內嵌的C基類物件的資料也緊跟在H的資料之後。但是，在I物件中，記憶體佈局就並非如此了。VC++實現的記憶體佈局中，G物件例項中G物件和C物件之間的偏移，不同於I物件例項中G物件和C物件之間的偏移。當使用指標訪問虛基類成員變數時，由於指標可以是指向派生類例項的基類指標，所以，編譯器不能根據宣告的指標型別計算偏移，而必須找到另一種間接的方法，從派生類指標計算虛基類的位置。
在VC++中，對每個繼承自虛基類的類例項，將增加一個隱藏的“虛基類表指標”（vbptr）成員變數，從而達到間接計算虛基類位置的目的。該變數指向一個全類共享的偏移量表，表中專案記錄了對於該類而言，“虛基類表指標”與虛基類之間的偏移量。
其它的實現方式中，有一種是在派生類中使用指標成員變數。這些指標成員變數指向派生類的虛基類，每個虛基類一個指標。這種方式的優點是：獲取虛基類地址時，所用程式碼比較少。然而，編譯器優化程式碼時通常都可以採取措施避免重複計算虛基類地址。況且，這種實現方式還有一個大弊端：從多個虛基類派生時，類例項將佔用更多的記憶體空間；獲取虛基類的虛基類的地址時，需要多次使用指標，從而效率較低等等。
在VC++中，G擁有一個隱藏的“虛基類表指標”成員，指向一個虛基類表，該表的第二項是GdGvbptrC。（在G中，虛基類物件C的地址與G的“虛基類表指標”之間的偏移量（當對於所有的派生類來說偏移量不變時，省略“d”前的字首））。比如，在32位平臺上，GdGvptrC是8個位元組。同樣，在I例項中的G物件例項也有“虛基類表指標”，不過該指標指向一個適用於“G處於I之中”的虛基類表，表中一項為IdGvbptrC，值為20。
觀察前面的G、H和I，我們可以得到如下關於VC++虛繼承下記憶體佈局的結論：
• 首先排列非虛繼承的基類例項；
• 有虛基類時，為每個基類增加一個隱藏的vbptr，除非已經從非虛繼承的類那裡繼承了一個vbptr；
• 排列派生類的新資料成員；
• 在例項最後，排列每個虛基類的一個例項。
該佈局安排使得虛基類的位置隨著派生類的不同而“浮動不定”，但是，非虛基類因此也就湊在一起，彼此的偏移量固定不變。
3 成員變數
介紹了類佈局之後，我們接著考慮對不同的繼承方式，訪問成員變數的開銷究竟如何。
沒有繼承。沒有任何繼承關係時，訪問成員變數和C語言的情況完全一樣：從指向物件的指標，考慮一定的偏移量即可。
C* pc;
pc->c1; // *(pc + dCc1);
譯者注：pc是指向C的指標。
• 訪問C的成員變數c1，只需要在pc上加上固定的偏移量dCc1（在C中，C指標地址與其c1成員變數之間的偏移量值），再獲取該指標的內容即可。
單繼承。由於派生類例項與其基類例項之間的偏移量是常數0，所以，可以直接利用基類指標和基類成員之間的偏移量關係，如此計算得以簡化。
D* pd;
pd->c1; // (pd + dDC + dCc1); // (pd + dDc1);
pd->d1; // *(pd + dDd1);
譯者注：D從C單繼承，pd為指向D的指標。
• 當訪問基類成員c1時，計算步驟本來應該為“pd+dDC+dCc1”，即為先計算D物件和C物件之間的偏移，再在此基礎上加上C物件指標與成員變數c1之間的偏移量。然而，由於dDC恆定為0，所以直接計算C物件地址與c1之間的偏移就可以了。
• 當訪問派生類成員d1時，直接計算偏移量。
多重繼承。雖然派生類與某個基類之間的偏移量可能不為0，然而，該偏移量總是一個常數。只要是個常數，訪問成員變數，計算成員變數偏移時的計算就可以被簡化。可見即使對於多重繼承來說，訪問成員變數開銷仍然不大。
F* pf;
pf->c1; // (pf + dFC + dCc1); // (pf + dFc1);
pf->e1; // (pf + dFE + dEe1); // (pf + dFe1);
pf->f1; // *(pf + dFf1);
譯者注：F繼承自C和E，pf是指向F物件的指標。
• 訪問C類成員c1時，F物件與內嵌C物件的相對偏移為0，可以直接計算F和c1的偏移；
• 訪問E類成員e1時，F物件與內嵌E物件的相對偏移是一個常數，F和e1之間的偏移計算也可以被簡化；
• 訪問F自己的成員f1時，直接計算偏移量。
虛繼承。當類有虛基類時，訪問非虛基類的成員仍然是計算固定偏移量的問題。然而，訪問虛基類的成員變數，開銷就增大了，因為必須經過如下步驟才能獲得成員變數的地址：獲取“虛基類表指標”；獲取虛基類表中某一表項的內容；把內容中指出的偏移量加到“虛基類表指標”的地址上。然而，事情並非永遠如此。正如下面訪問I物件的c1成員那樣，如果不是通過指標訪問，而是直接通過物件例項，則派生類的佈局可以在編譯期間靜態獲得，偏移量也可以在編譯時計算，因此也就不必要根據虛基類表的表項來間接計算了。
I* pi;
pi->c1; // (pi + dIGvbptr + ((pi+dIGvbptr))[1] + dCc1);
pi->g1; // (pi + dIG + dGg1); // (pi + dIg1);
pi->h1; // (pi + dIH + dHh1); // (pi + dIh1);
pi->i1; // *(pi + dIi1);
I i;
i.c1; // (&i + IdIC + dCc1); // (&i + IdIc1);
譯者注：I繼承自G和H，G和H的虛基類是C，pi是指向I物件的指標。
• 訪問虛基類C的成員c1時，dIGvbptr是“在I中，I物件指標與G的“虛基類表指標”之間的偏移”，(pi + dIGvbptr)是虛基類表的開始地址，(pi + dIGvbptr)[1]是虛基類表的第二項的內容（在I物件中，G物件的“虛基類表指標”與虛基類之間的偏移），dCc1是C物件指標與成員變數c1之間的偏移；
• 訪問非虛基類G的成員g1時，直接計算偏移量；
• 訪問非虛基類H的成員h1時，直接計算偏移量；
• 訪問自身成員i1時，直接使用偏移量；
• 當聲明瞭一個物件例項，用點“.”操作符訪問虛基類成員c1時，由於編譯時就完全知道物件的佈局情況，所以可以直接計算偏移量。
當訪問類繼承層次中，多層虛基類的成員變數時，情況又如何呢？比如，訪問虛基類的虛基類的成員變數時？一些實現方式為：儲存一個指向直接虛基類的指標，然後就可以從直接虛基類找到它的虛基類，逐級上推。VC++優化了這個過程。VC++在虛基類表中增加了一些額外的項，這些項儲存了從派生類到其各層虛基類的偏移量。
4 強制轉化
如果沒有虛基類的問題，將一個指標強制轉化為另一個型別的指標代價並不高昂。如果在要求轉化的兩個指標之間有“基類-派生類”關係，編譯器只需要簡單地在兩者之間加上或者減去一個偏移量即可（並且該量還往往為0）。
F* pf;
(C*)pf; // (C*)(pf ? pf + dFC : 0); // (C*)pf;
(E*)pf; // (E*)(pf ? pf + dFE : 0);
C和E是F的基類，將F的指標pf轉化為C*或E*，只需要將pf加上一個相應的偏移量。轉化為C型別指標C*時，不需要計算，因為F和C之間的偏移量為0。轉化為E型別指標E*時，必須在指標上加一個非0的偏移常量dFE。C++規範要求NULL指標在強制轉化後依然為NULL，因此在做強制轉化需要的運算之前，VC++會檢查指標是否為NULL。當然，這個檢查只有當指標被顯示或者隱式轉化為相關型別指標時才進行；當在派生類物件中呼叫基類的方法，從而派生類指標被在後臺轉化為一個基類的Const “this” 指標時，這個檢查就不需要進行了，因為在此時，該指標一定不為NULL。
正如你猜想的，當繼承關係中存在虛基類時，強制轉化的開銷會比較大。具體說來，和訪問虛基類成員變數的開銷相當。
I* pi;
(G*)pi; // (G*)pi;
(H*)pi; // (H*)(pi ? pi + dIH : 0);
(C*)pi; // (C*)(pi ? (pi+dIGvbptr + (*(pi+dIGvbptr))[1]) : 0);
譯者注：pi是指向I物件的指標，G,H是I的基類，C是G,H的虛基類。
• 強制轉化pi為G*時，由於G*和I*的地址相同，不需要計算；
• 強制轉化pi為H*時，只需要考慮一個常量偏移；
• 強制轉化pi為C*時，所作的計算和訪問虛基類成員變數的開銷相同，首先得到G的虛基類表指標，再從虛基類表的第二項中取出G到虛基類C的偏移量，最後根據pi、虛基類表偏移和虛基類C與虛基類表指標之間的偏移計算出C*。
一般說來，當從派生類中訪問虛基類成員時，應該先強制轉化派生類指標為虛基類指標，然後一直使用虛基類指標來訪問虛基類成員變數。這樣做，可以避免每次都要計算虛基類地址的開銷。見下例。
/* before: */ … pi->c1 … pi->c1 …
/* faster: / C pc = pi; … pc->c1 … pc->c1 …
譯者注：前者一直使用派生類指標pi，故每次訪問c1都有計算虛基類地址的較大開銷；後者先將pi轉化為虛基類指標pc，故後續呼叫可以省去計算虛基類地址的開銷。
5 成員函式
一個C++成員函式只是類範圍內的又一個成員。X類每一個非靜態的成員函式都會接受一個特殊的隱藏引數——this指標，型別為X* const。該指標在後臺初始化為指向成員函式工作於其上的物件。同樣，在成員函式體內，成員變數的訪問是通過在後臺計算與this指標的偏移來進行。

struct P {
int p1;
void pf(); // new
virtual void pvf(); // new
};
P有一個非虛成員函式pf()，以及一個虛成員函式pvf()。很明顯，虛成員函式造成物件例項佔用更多記憶體空間，因為虛成員函式需要虛擬函式表指標。這一點以後還會談到。這裡要特別指出的是，宣告非虛成員函式不會造成任何物件例項的記憶體開銷。現在，考慮P::pf()的定義。
void P::pf() { // void P::pf([P *const this])
++p1; // ++(this->p1);
}
這裡P:pf()接受了一個隱藏的this指標引數，對於每個成員函式呼叫，編譯器都會自動加上這個引數。同時，注意成員變數訪問也許比看起來要代價高昂一些，因為成員變數訪問通過this指標進行，在有的繼承層次下，this指標需要調整，所以訪問的開銷可能會比較大。然而，從另一方面來說，編譯器通常會把this指標快取到暫存器中，所以，成員變數訪問的代價不會比訪問區域性變數的效率更差。
譯者注：訪問區域性變數，需要到SP暫存器中得到棧指標，再加上區域性變數與棧頂的偏移。在沒有虛基類的情況下，如果編譯器把this指標快取到了暫存器中，訪問成員變數的過程將與訪問區域性變數的開銷相似。
5.1 覆蓋成員函式
和成員變數一樣，成員函式也會被繼承。與成員變數不同的是，通過在派生類中重新定義基類函式，一個派生類可以覆蓋，或者說替換掉基類的函式定義。覆蓋是靜態（根據成員函式的靜態型別在編譯時決定）還是動態（通過物件指標在執行時動態決定），依賴於成員函式是否被宣告為“虛擬函式”。
Q從P繼承了成員變數和成員函式。Q聲明瞭pf()，覆蓋了P::pf()。Q還聲明瞭pvf()，覆蓋了P::pvf()虛擬函式。Q還聲明瞭新的非虛成員函式qf()，以及新的虛成員函式qvf()。

struct Q : P {
int q1;
void pf(); // overrides P::pf
void qf(); // new
void pvf(); // overrides P::pvf
virtual void qvf(); // new
};
對於非虛的成員函式來說，呼叫哪個成員函式是在編譯時，根據“->”操作符左邊指標表示式的型別靜態決定的。特別地，即使ppq指向Q的例項，ppq->pf()仍然呼叫的是P::pf()，因為ppq被宣告為“P*”。（注意，“->”操作符左邊的指標型別決定隱藏的this引數的型別。）
P p; P* pp = &p; Q q; P* ppq = &q; Q* pq = &q;
pp->pf(); // pp->P::pf(); // P::pf(pp);
ppq->pf(); // ppq->P::pf(); // P::pf(ppq);
pq->pf(); // pq->Q::pf(); // Q::pf((P*)pq); （錯誤!）
pq->qf(); // pq->Q::qf(); // Q::qf(pq);
譯者注：標記“錯誤”處，P*似應為Q*。因為pf非虛擬函式，而pq的型別為Q*，故應該呼叫到Q的pf函式上，從而該函式應該要求一個Q* const型別的this指標。
對於虛擬函式呼叫來說，呼叫哪個成員函式在執行時決定。不管“->”操作符左邊的指標表示式的型別如何，呼叫的虛擬函式都是由指標實際指向的例項型別所決定。比如，儘管ppq的型別是P*，當ppq指向Q的例項時，呼叫的仍然是Q::pvf()。
pp->pvf(); // pp->P::pvf(); // P::pvf(pp);
ppq->pvf(); // ppq->Q::pvf(); // Q::pvf((Q*)ppq);
pq->pvf(); // pq->Q::pvf(); // Q::pvf((P*)pq); （錯誤！）
譯者注：標記“錯誤”處，P*似應為Q*。因為pvf是虛擬函式，pq本來就是Q*，又指向Q的例項，從哪個方面來看都不應該是P*。
為了實現這種機制，引入了隱藏的vfptr成員變數。一個vfptr被加入到類中（如果類中沒有的話），該vfptr指向類的虛擬函式表（vftable）。類中每個虛擬函式在該類的虛擬函式表中都佔據一項。每項儲存一個對於該類適用的虛擬函式的地址。因此，呼叫虛擬函式的過程如下：取得例項的vfptr；通過vfptr得到虛擬函式表的一項；通過虛擬函式表該項的函式地址間接呼叫虛擬函式。也就是說，在普通函式呼叫的引數傳遞、呼叫、返回指令開銷外，虛擬函式呼叫還需要額外的開銷。
回頭再看看P和Q的記憶體佈局，可以發現，VC++編譯器把隱藏的vfptr成員變數放在P和Q例項的開始處。這就使虛擬函式的呼叫能夠儘量快一些。實際上，VC++的實現方式是，保證任何有虛擬函式的類的第一項永遠是vfptr。這就可能要求在例項佈局時，在基類前插入新的vfptr，或者要求在多重繼承時，雖然在右邊，然而有vfptr的基類放到左邊沒有vfptr的基類的前面（如下）。
class CA
{ int a;};

class CB
{ int b;};

class CL : public CB, public CA
{ int c;};

以上的類繼承, 對CL類說, 他的記憶體佈局是

int b;
int a;
int c;

但是, 改造CA如下:
class CA
{
int a;
virtual void seta( int _a ) { a = _a; }
};

同樣繼承順序的CL, 記憶體中佈局是
vfptr
int a;
int b;
int c;

CA被提到CB前面, 這樣的佈局是因為 class 的佈局就是 vfptr肯定要放在最前面.

許多C++的實現會共享或者重用從基類繼承來的vfptr。比如，Q並不會有一個額外的vfptr，指向一個專門存放新的虛擬函式qvf()的虛擬函式表。Qvf項只是簡單地追加到P的虛擬函式表的末尾。如此一來，單繼承的代價就不算高昂。一旦一個例項有vfptr了，它就不需要更多的vfptr。新的派生類可以引入更多的虛擬函式，這些新的虛擬函式只是簡單地在已存在的，“每類一個”的虛擬函式表的末尾追加新項。

5.2 多重繼承下的虛擬函式
如果從多個有虛擬函式的基類繼承，一個例項就有可能包含多個vfptr。考慮如下的R和S類：

struct R {
int r1;
virtual void pvf(); // new
virtual void rvf(); // new
};

struct S : P, R {
int s1;
void pvf(); // overrides P::pvf and R::pvf
void rvf(); // overrides R::rvf
void svf(); // new
};
這裡R是另一個包含虛擬函式的類。因為S從P和R多重繼承，S的例項內嵌P和R的例項，以及S自身的資料成員S::s1。注意，在多重繼承下，靠右的基類R，其例項的地址和P與S不同。S::pvf覆蓋了P::pvf()和R::pvf()，S::rvf()覆蓋了R::rvf()。
S s; S* ps = &s;
((P*)ps)->pvf(); // ((P)ps)->P::vfptr[0])((S*)(P*)ps)
((R*)ps)->pvf(); // ((R)ps)->R::vfptr[0])((S*)(R*)ps)
ps->pvf(); // one of the above; calls S::pvf()
譯者注：
• 呼叫((P*)ps)->pvf()時，先到P的虛擬函式表中取出第一項，然後把ps轉化為S*作為this指標傳遞進去；
• 呼叫((R*)ps)->pvf()時，先到R的虛擬函式表中取出第一項，然後把ps轉化為S*作為this指標傳遞進去；
因為S::pvf()覆蓋了P::pvf()和R::pvf()，在S的虛擬函式表中，相應的項也應該被覆蓋。然而，我們很快注意到，不光可以用P*，還可以用R*來呼叫pvf()。問題出現了：R的地址與P和S的地址不同。表示式(R*)ps與表示式(P*)ps指向類佈局中不同的位置。因為函式S::pvf希望獲得一個S*作為隱藏的this指標引數，虛擬函式必須把R*轉化為S*。因此，在S對R虛擬函式表的拷貝中，pvf函式對應的項，指向的是一個“調整塊”的地址，該調整塊使用必要的計算，把R*轉換為需要的S*。
譯者注：這就是“thunk1: this-= sdPR; goto S::pvf”乾的事。先根據P和R在S中的偏移，調整this為P*，也就是S*，然後跳轉到相應的虛擬函式處執行。
在微軟VC++實現中，對於有虛擬函式的多重繼承，只有當派生類虛擬函式覆蓋了多個基類的虛擬函式時，才使用調整塊。
5.3 地址點與“邏輯this調整”
考慮下一個虛擬函式S::rvf()，該函式覆蓋了R::rvf()。我們都知道S::rvf()必須有一個隱藏的S*型別的this引數。但是，因為也可以用R*來呼叫rvf()，也就是說，R的rvf虛擬函式槽可能以如下方式被用到：
((R*)ps)->rvf(); // (((R)ps)->R::vfptr[1])((R*)ps)
所以，大多數實現用另一個調整塊將傳遞給rvf的R*轉換為S*。還有一些實現在S的虛擬函式表末尾新增一個特別的虛擬函式項，該虛擬函式項提供方法，從而可以直接呼叫ps->rvf()，而不用先轉換R*。MSC++的實現不是這樣，MSC++有意將S::rvf編譯為接受一個指向S中巢狀的R例項，而非指向S例項的指標（我們稱這種行為是“給派生類的指標型別與該虛擬函式第一次被引入時接受的指標型別相同”）。所有這些在後臺透明發生，對成員變數的存取，成員函式的this指標，都進行“邏輯this調整”。
當然，在debugger中，必須對這種this調整進行補償。
ps->rvf(); // ((R*)ps)->rvf(); // S::rvf((R*)ps)
譯者注：呼叫rvf虛擬函式時，直接給入R*作為this指標。
所以，當覆蓋非最左邊的基類的虛擬函式時，MSC++一般不建立調整塊，也不增加額外的虛擬函式項。
5.4 調整塊
正如已經描述的，有時需要調整塊來調整this指標的值（this指標通常位於棧上返回地址之下，或者在暫存器中），在this指標上加或減去一個常量偏移，再呼叫虛擬函式。某些實現（尤其是基於cfront的）並不使用調整塊機制。它們在每個虛擬函式表項中增加額外的偏移資料。每當虛擬函式被呼叫時，該偏移資料（通常為0）,被加到物件的地址上，然後物件的地址再作為this指標傳入。
ps->rvf();
// struct { void (pfn)(void); size_t disp; };
// (*ps->vfptr[i].pfn)(ps + ps->vfptr[i].disp);
譯者注：當呼叫rvf虛擬函式時，前一句表示虛擬函式表每一項是一個結構，結構中包含偏移量；後一句表示呼叫第i個虛擬函式時，this指標使用儲存在虛擬函式表中第i項的偏移量來進行調整。
這種方法的缺點是虛擬函式表增大了，虛擬函式的呼叫也更加複雜。
現代基於PC的實現一般採用“調整—跳轉”技術：
S::pvf-adjust: // MSC++
this -= SdPR;
goto S::pvf()
當然，下面的程式碼序列更好（然而，當前沒有任何實現採用該方法）：
S::pvf-adjust:
this -= SdPR; // fall into S::pvf()
S::pvf() { … }
譯者注：IBM的C++編譯器使用該方法。

5.5 虛繼承下的虛擬函式
T虛繼承P，覆蓋P的虛成員函式，聲明瞭新的虛擬函式。如果採用在基類虛擬函式表末尾新增新項的方式，則訪問虛擬函式總要求訪問虛基類。在VC++中，為了避免獲取虛擬函式表時，轉換到虛基類P的高昂代價，T中的新虛擬函式通過一個新的虛擬函式表獲取，從而帶來了一個新的虛擬函式表指標。該指標放在T例項的頂端。

struct T : virtual P {
int t1;
void pvf(); // overrides P::pvf
virtual void tvf(); // new
};
void T::pvf() {
++p1; // ((P*)this)->p1++; // vbtable lookup!
++t1; // this->t1++;
}
如上所示，即使是在虛擬函式中，訪問虛基類的成員變數也要通過獲取虛基類表的偏移，實行計算來進行。這樣做之所以必要，是因為虛擬函式可能被進一步繼承的類所覆蓋，而進一步繼承的類的佈局中，虛基類的位置變化了。下面就是這樣的一個類：

struct U : T {
int u1;
};
在此U增加了一個成員變數，從而改變了P的偏移。因為VC++實現中，T::pvf()接受的是巢狀在T中的P的指標，所以，需要提供一個調整塊，把this指標調整到T::t1之後（該處即是P在T中的位置）。
5.6 特殊成員函式
本節討論編譯器合成到特殊成員函式中的隱藏程式碼。
5.6.1 建構函式和解構函式
正如我們所見，在構造和析構過程中，有時需要初始化一些隱藏的成員變數。最壞的情況下，一個建構函式要執行如下操作：
• * 如果是“最終派生類”，初始化vbptr成員變數，呼叫虛基類的建構函式；
• * 呼叫非虛基類的建構函式
• * 呼叫成員變數的建構函式
• * 初始化虛擬函式表成員變數
• * 執行建構函式體中，程式所定義的其他初始化程式碼
（注意：一個“最終派生類”的例項，一定不是巢狀在其他派生類例項中的基類例項）
所以，如果你有一個包含虛擬函式的很深的繼承層次，即使該繼承層次由單繼承構成，物件的構造可能也需要很多針對虛擬函式表的初始化。
反之，解構函式必須按照與構造時嚴格相反的順序來“肢解”一個物件。
• * 合成並初始化虛擬函式表成員變數
• * 執行解構函式體中，程式定義的其他析構程式碼
• * 呼叫成員變數的解構函式（按照相反的順序）
• * 呼叫直接非虛基類的解構函式（按照相反的順序）
• * 如果是“最終派生類”，呼叫虛基類的解構函式（按照相反順序）
在VC++中，有虛基類的類的建構函式接受一個隱藏的“最終派生類標誌”，標示虛基類是否需要初始化。對於解構函式，VC++採用“分層析構模型”，程式碼中加入一個隱藏的解構函式，該函式被用於析構包含虛基類的類（對於“最終派生類”例項而言）；程式碼中再加入另一個解構函式，析構不包含虛基類的類。前一個解構函式呼叫後一個。
5.6.2 虛解構函式與delete操作符
假如A是B的父類，
A* p = new B();
如果解構函式不是虛擬的，那麼，你後面就必須這樣才能安全的刪除這個指標：
delete (B*)p;
但如果建構函式是虛擬的，就可以在執行時動態繫結到B類的解構函式，直接：
delete p;
就可以了。這就是虛解構函式的作用。
實際上，很多人這樣總結：當且僅當類裡包含至少一個虛擬函式的時候才去宣告虛解構函式。
考慮結構V和W。

struct V {
virtual ~V();
};

struct W : V {
operator delete();
};
解構函式可以為虛。一個類如果有虛解構函式的話，將會象有其他虛擬函式一樣，擁有一個虛擬函式表指標，虛擬函式表中包含一項，其內容為指向對該類適用的虛解構函式的地址。這些機制和普通虛擬函式相同。虛解構函式的特別之處在於：當類例項被銷燬時，虛解構函式被隱含地呼叫。呼叫地（delete發生的地方）雖然不知道銷燬的動態型別，然而，要保證呼叫對該型別合適的delete操作符。例如，當pv指向W的例項時，當W::~W被呼叫之後，W例項將由W類的delete操作符來銷燬。
V* pv = new V;
delete pv; // pv->~V::V(); // use ::operator delete()
pv = new W;
delete pv; // pv->~W::W(); // use W::operator delete() 動態繫結到 W的解構函式，W預設的解構函式呼叫{delete this;}
pv = new W;
::delete pv; // pv->~W::W(); // use ::operator delete()
譯者注：
• V沒有定義delete操作符，delete時使用函式庫的delete操作符；
• W定義了delete操作符，delete時使用自己的delete操作符；
• 可以用全域性範圍標示符顯示地呼叫函式庫的delete操作符。
為了實現上述語意，VC++擴充套件了其“分層析構模型”，從而自動建立另一個隱藏的析構幫助函式——“deleting解構函式”，然後，用該函式的地址來替換虛擬函式表中“實際”虛解構函式的地址。析構幫助函式呼叫對該類合適的解構函式，然後為該類有選擇性地呼叫合適的delete操作符。
6 陣列
堆上分配空間的陣列使虛解構函式進一步複雜化。問題變複雜的原因有兩個：
1、 堆上分配空間的陣列，由於陣列可大可小，所以，陣列大小值應該和陣列一起儲存。因此，堆上分配空間的陣列會分配額外的空間來儲存陣列元素的個數；
2、 當陣列被刪除時，陣列中每個元素都要被正確地釋放，即使當陣列大小不確定時也必須成功完成該操作。然而，派生類可能比基類佔用更多的記憶體空間，從而使正確釋放比較困難。
struct WW : W { int w1; };
pv = new W[m];
delete [] pv; // delete m W’s (sizeof(W) == sizeof(V))
pv = new WW[n];
delete [] pv; // delete n WW’s (sizeof(WW) > sizeof(V))
譯者注：WW從W繼承，增加了一個成員變數，因此，WW佔用的記憶體空間比W大。然而，不管指標pv指向W的陣列還是WW的陣列，delete[]都必須正確地釋放WW或W物件佔用的記憶體空間。
雖然從嚴格意義上來說，陣列delete的多型行為C++標準並未定義，然而，微軟有一些客戶要求實現該行為。因此，在MSC++中，該行為是用另一個編譯器生成的虛析構幫助函式來完成。該函式被稱為“向量delete解構函式”（因其針對特定的類定製，比如WW，所以，它能夠遍歷陣列的每個元素，呼叫對每個元素適用的解構函式）。
7 異常處理
簡單說來，異常處理是C++標準委員會工作檔案提供的一種機制，通過該機制，一個函式可以通知其呼叫者“異常”情況的發生，呼叫者則能據此選擇合適的程式碼來處理異常。該機制在傳統的“函式呼叫返回，檢查錯誤狀態程式碼”方法之外，給程式提供了另一種處理錯誤的手段。
因為C++是面向物件的語言，很自然地，C++中用物件來表達異常狀態。並且，使用何種異常處理也是基於“丟擲的”異常物件的靜態或動態型別來決定的。不光如此，既然C++總是保證超出範圍的物件能夠被正確地銷燬，異常實現也必須保證當控制從異常丟擲點轉換到異常“捕獲”點時（棧展開），超出範圍的物件能夠被自動、正確地銷燬。
考慮如下例子：
struct X { X(); }; // exception object class
struct Z { Z(); ~Z(); }; // class with a destructor
extern void recover(const X&);
void f(int), g(int);
int main() {
try {
f(0);
} catch (const X& rx) {
recover(rx);
}
return 0;
}
void f(int i) {
Z z1;
g(i);
Z z2;
g(i-1);
}
void g(int j) {
if (j < 0)
throw X();
}
譯者注：X是異常類，Z是帶解構函式的工作類，recover是錯誤處理函式，f和g一起產生異常條件，g實際丟擲異常。
這段程式會丟擲異常。在main中，加入了處理異常的try & catch框架，當呼叫f(0)時，f構造z1，呼叫g(0)後，再構造z2，再呼叫g(-1)，此時g發現引數為負，丟擲X異常物件。我們希望在某個呼叫層次上，該異常能夠得到處理。既然g和f都沒有建立處理異常的框架，我們就只能希望main函式建立的異常處理框架能夠處理X異常物件。實際上，確實如此。當控制被轉移到main中異常捕獲點時，從g中的異常丟擲點到main中的異常捕獲點之間，該範圍內的物件都必須被銷燬。在本例中，z2和z1應該被銷燬。
談到異常處理的具體實現方式，一般情況下，在丟擲點和捕獲點都使用“表”來表述能夠捕獲異常物件的型別；並且，實現要保證能夠在特定的捕獲點真正捕獲特定的異常物件；一般地，還要運用丟擲的物件來初始化捕獲語句的“實參”。通過合理地選擇編碼方案，可以保證這些表格不會佔用過多的記憶體空間。
異常處理的開銷到底如何？讓我們再考慮一下函式f。看起來f沒有做異常處理。f確實沒有包含try，catch，或者是throw關鍵字，因此，我們會猜異常處理應該對f沒有什麼影響。錯！編譯器必須保證一旦z1被構造，而後續呼叫的任何函式向f拋回了異常，異常又出了f的範圍時，z1物件能被正確地銷燬。同樣，一旦z2被構造，編譯器也必須保證後續丟擲異常時，能夠正確地銷燬z2和z1。
要實現這些“展開”語意，編譯器必須在後臺提供一種機制，該機制在呼叫者函式中，針對呼叫的函式丟擲的異常動態決定異常環境（處理點）。這可能包括在每個函式的準備工作和善後工作中增加額外的程式碼，在最糟糕的情況下，要針對每一套物件初始化的情況更新狀態變數。例如，上述例子中，z1應被銷燬的異常環境當然與z2和z1都應該被銷燬的異常環境不同，因此，不管是在構造z1後，還是繼而在構造z2後，VC++都要分別在狀態變數中更新（儲存）新的值。
所有這些表，函式呼叫的準備和善後工作，狀態變數的更新，都會使異常處理功能造成可觀的記憶體空間和執行速度開銷。正如我們所見，即使在沒有使用異常處理的函式中，該開銷也會發生。
幸運的是，一些編譯器可以提供編譯選項，關閉異常處理機制。那些不需要異常處理機制的程式碼，就可以避免這些額外的開銷了。
8 小結
好了，現在你可以寫C++編譯器了（開個玩笑）。
在本文中，我們討論了許多重要的C++執行實現問題。我們發現，很多美妙的C++語言特性的開銷很低，同時，其他一些美妙的特性（譯者注：主要是和“虛”字相關的東西）將造成較大的開銷。C++很多實現機制都是在後臺默默地為你工作。一般說來，單獨看一段程式碼時，很難衡量這段程式碼造成的執行時開銷，必須把這段程式碼放到一個更大的環境中來考察，執行時開銷問題才能得到比較明確的答案。