多繼承與虛函數(shù)重復
既然說到了多繼承，那么還有一個問題可能會需要解決，那就是如果兩個父類里都有相同的虛函數(shù)定義，在子對象的布局里會是怎么樣個情況？是否依然可以將這個虛函數(shù)指向到正確的實現(xiàn)代碼上呢？
修改前面一個源代碼，在parent2的接口里增加下面的虛函數(shù)定義：
virtual int fun1（）{cout<<"parent2：：fun1（）"<<endl；return 0；}；
上面的fun1的定義與parent1類里的完全重復相同（類型，參數(shù)列表），增加上面的代碼后立即開始編譯，程序正常編譯通過。運行之，得到下面的結(jié)果：
child1：：fun1（）
child1：：fun2（）
這個程序居然正確的完成了執(zhí)行，編譯器在其中做了些怎樣的工作，是怎么樣避免掉隊fun1函數(shù)的沖突問題呢？
讓我們來看看這個時候的child1的對象布局：
class child1 size(8):
+---
| +--- (base class parent1)
0 | | {vfptr}
| +---
| +--- (base class parent2)
4 | | {vfptr}
| +---
+---
child1::$vftable@parent1@:
| &child1_meta
| 0
0 | &child1::fun1
child1::$vftable@parent2@:
| -4
0 | &child1::fun2
1 | &thunk: this-=4; goto child1::fun1
child1::fun1 this adjustor: 0
child1::fun2 this adjustor: 4
恩~~~還是兩個vfptr在child1的對象布局里（不一樣就怪啦，呵呵），但是第二個vfptr所指的虛函數(shù)表的內(nèi)容有所變化哦！
注意看紅色字體部分，虛函數(shù)表里并沒有直接填寫child：：fun1的代碼，而是多了一個 &thunk： this-=4；然后才goto child1：：fun1！注意到一個關(guān)鍵名詞thunk了吧？沒錯，vc在這里使用了名為thunk的技術(shù)，避免了虛函數(shù)fun1在兩個基類里重復出現(xiàn)導致的沖突問題！（除了thunk，還有其他方法可以解決此類問題的）。
現(xiàn)在，我們知道為什么相同的虛函數(shù)不會在子類里出現(xiàn)沖突的情況了。
但是，倘若我們在基類里就是由兩個沖突的普通函數(shù)，而不是虛函數(shù)，是個怎樣的情況呢？
多繼承產(chǎn)生的沖突與虛繼承，虛基類
我們在parent1和parent2里添加一個相同的函數(shù)void fun3（），然后再進行編譯，通過了！查看類對象布局，跟上面的完全一致。但是在main函數(shù)里調(diào)用chobj.fun3（）的時候，編譯器卻不再能正確編譯了，并且會提示“error C2385： 對”fun3“的訪問不明確”的錯誤信息，沒錯，編譯器不知道你要訪問哪個fun3了。
如何解決這樣的多繼承帶來的問題呢，其實有一個簡單的做法。就是在方法前限定引用的具體是哪個類的函數(shù)，比如：chobj.parent1：：fun3（）； ，這樣的寫法就寫明了是要調(diào)用chobj的父類parent1里的fun3（）函數(shù)！
我們再看看另外一種情況，從parent1和parent2里抹去剛才添加的fun3函數(shù)，將之放到一個共同的基類里：
class commonbase
{
public：
void fun3（）{cout<<"commonbase：：fun3（）"<<endl；}
}；
而parent1和parent2都修改為從此類繼承。可以看到，在這個情況下，依然需要使用chobj.parent1：：fun3（）； 的方式才可以正確調(diào)用到fun3，難道，在這種情況下，就不能自然的使用chobj.fun3（）這樣的方式了嗎？
虛繼承可以解決這個問題——我們在parent1和parent2繼承common類的地方添加上一個關(guān)鍵詞virtual，如下：
class parent1：virtual public commonbase
{
public：
virtual int fun1（）{cout<<"parent1：：fun1（）"<<endl；return 0；}；
}；
給parent2也同樣的處理，然后再次編譯，這次chobj.fun3（）可以編譯通過了！！！
編譯器這次又在私下里做了哪些工作了呢？？？？
class child1 size(16):
+---
| +--- (base class parent1)
0 | | {vfptr}
4 | | {vbptr}
| +---
| +--- (base class parent2)
8 | | {vfptr}
12 | | {vbptr}
| +---
+---
+--- (virtual base commonbase)
+---
child1::$vftable@parent1@:
| &child1_meta
| 0
0 | &child1::fun1
child1::$vftable@parent2@:
| -8
0 | &child1::fun2
1 | &thunk: this-=8; goto child1::fun1
child1::$vbtable@parent1@:
0 | -4
1 | 12 (child1d(parent1+4)commonbase)
child1::$vbtable@parent2@:
0 | -4
1 | 4 (child1d(parent2+4)commonbase)
child1::fun1 this adjustor: 0
child1::fun2 this adjustor: 8
vbi: class offset o.vbptr o.vbte fVtorDisp
commonbase 16 4 4 0
這次變化可大了去了！！！
首先，可以看到兩個類parent1和parent2的對象布局里，都多了一個vbptr的指針。而在child1的對象布局里，還有一個virtual base commonbase的虛擬基類。再看看兩個vbptr的內(nèi)容：
12 （child1d（parent1+4）commonbase） 這個很好理解，從parent1的vbptr開始，偏移12個字節(jié)，指向的是virtual base commonbase！
再看看4 （child1d（parent2+4）commonbase） ，從parent2的vbptr開始，便宜4個字節(jié)，也指向了virtual base commonbase！
這下明白了。虛基類在child1里只有一個共同的對象布局了，所以就可以直接用chobj.fun3（）啦，當然，在commonbase里的其他成員變量此時也可以同樣的方式訪問了！
雖然解決方案有了，但是在一個系統(tǒng)的設(shè)計里，如果有一個基類出現(xiàn)多繼承沖突的情況，大部分情況下都說明這樣的設(shè)計是有問題的，應該盡量避免這樣的設(shè)計，并且盡量用純虛函數(shù)，來提取一些抽象的接口類，把共同的方法接口都抽取出來，通常就能避免多繼承的問題。