http://www.cnblogs.com/DylanWind/archive/2009/01/12/1373919.html
前部分原創，轉載請注明出處，謝謝！
class Base
{
public:
int m_base;
};
class DerivedA: public Base
int m_derivedA;
class DerivedB: public Base
int m_derivedB;
class DerivedC: public DerivedA, public DerivedB
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_base 隻有一份
類似于這個：
=================================================================
Base, DerivedA, DerivedB 各增加一個虛函數
則記憶體布局為：
DerivedB：
DerivedB::vfptr
DerivedB::vbptr
DerivedB::m_derivedB
Base::vfptr
Base::m_base
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), 子類的元素
2. 普通繼承+父類有virtual函數
不管子類沒有新定義virtual函數 此時子類的布局是 :
低位址 -> 高位址
父類的元素(包含vfptr), 子類的元素.
如果子類有新定義的virtual函數,那麼在父類的vfptr(也就是第一個vptr)對應的vtable中添加一個函數指針.
3.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 { ... }; 如果經理類和勞工類都繼承自雇員類，很自然地，它們每個類都會從雇員類獲得一份資料拷貝。如果不作特殊處理，一線經理類的執行個體将含有兩個雇員類執行個體，它們分别來自兩個雇員基類。如果雇員類成員變量不多，問題不嚴重；如果成員變量衆多，則那份多餘的拷貝将造成執行個體生成時的嚴重開銷。更糟的是，這兩份不同的雇員執行個體可能分别被修改，造成資料的不一緻。是以，我們需要讓經理類和勞工類進行特殊的聲明，說明它們願意共享一份雇員基類執行個體資料。 很不幸，在C++中，這種“共享繼承”被稱為“虛繼承”，把問題搞得似乎很抽象。虛繼承的文法很簡單，在指定基類時加上virtual關鍵字即可。 struct Manager : virtual Employee { ... }; struct Worker : virtual Employee { ... }; 使用虛繼承，比起單繼承和多重繼承有更大的實作開銷、調用開銷。回憶一下，在單繼承和多重繼承的情況下，内嵌的基類執行個體位址比起派生類執行個體位址來，要麼位址相同（單繼承，以及多重繼承的最靠左基類），要麼位址相差一個固定偏移量（多重繼承的非最靠左基類）。然而，當虛繼承時，一般說來，派生類位址和其虛基類位址之間的偏移量是不固定的，因為如果這個派生類又被進一步繼承的話，最終派生類會把共享的虛基類執行個體資料放到一個與上一層派生類不同的偏移量處。請看下例： 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）。 (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。 正如你猜想的，當繼承關系中存在虛基類時，強制轉化的開銷會比較大。具體說來，和通路虛基類成員變量的開銷相當。 (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如下: { int a; virtual void seta( int _a ) { a = _a; } 同樣繼承順序的CL, 記憶體中布局是 vfptr CA被提到CB前面, 這樣的布局是因為 class 的布局就是 vfptr肯定要放在最前面. 許多C++的實作會共享或者重用從基類繼承來的vfptr。比如，Q并不會有一個額外的vfptr，指向一個專門存放新的虛函數qvf()的虛函數表。Qvf項隻是簡單地追加到P的虛函數表的末尾。如此一來，單繼承的代價就不算高昂。一旦一個執行個體有vfptr了，它就不需要更多的vfptr。新的派生類可以引入更多的虛函數，這些新的虛函數隻是簡單地在已存在的，“每類一個”的虛函數表的末尾追加新項。 5.2 多重繼承下的虛函數 如果從多個有虛函數的基類繼承，一個執行個體就有可能包含多個vfptr。考慮如下的R和S類： struct R { int r1; 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;} ::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++很多實作機制都是在背景默默地為你工作。一般說來，單獨看一段代碼時，很難衡量這段代碼造成的運作時開銷，必須把這段代碼放到一個更大的環境中來考察，運作時開銷問題才能得到比較明确的答案。 |