青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

loop_in_codes

低調(diào)做技術(shù)__歡迎移步我的獨立博客 codemaro.com 微博 kevinlynx

多重繼承和void*的糗事

多重继承和void*的糗事

Author:Kevin Lynx
Date:4.30.2011

C++为了兼容C,导致了不少语言阴暗面。Bjarne Stroustrup在<D&E>一书里也常为此表现出无奈。另一方面,强制转换也是C++的一大诟病。但是,因为我们的应用环境总是那么“不 纯”,所以也就常常导致各种问题。

本文即描述了一个关于强制转换带来的问题。这个问题几年前我曾遇到过(<多线程下vc2003,vc2005对虚函数表处理的BUG?>),当时没来得及深究。深究C++的某些语法,实在是件辛苦事。所以,这里也不提过于诡异的用法。

问题

考虑下面非常普通的多重继承代码:

class Left {
public:
    virtual void ldisplay () {
        printf ("Left::ldisplay\n");
    }
};

class Right {
public:
    virtual void rdisplay () {
        printf ("Right::rdisplay\n");
    }
};

class Bottom : public Left, public Right {
public:
    virtual void ldisplay () {
        printf ("Bottom::ldisplay\n");
    }
};

这样子的代码在我们的项目中很容易就会出现,例如:

class BaseObject;
class EventListener;
class Player : public BaseObject, public EventListener

别紧张,我当然不会告诉你这样的代码是有安全隐患的。但它们确实在某些时候会出现隐患。在我们的C++项目中,也极有可能会与一些纯C模块打交道。在C语言里,极有肯能出现以 下的代码:

typedef void (*allocator) (void *u);
void set_allocator (allocator alloc, void *u);

之所以使用回调函数,是出于对模块的通用性的考虑。而在调用回调函数时,也通常会预留一个user data的指针,用于让应用层自由地传递数据。

以上关于多重继承和void*的使用中,都属于很常规的用法。但是当它们遇到一起时,事情就悲剧了。考虑下面的代码:

Bottom *bobj = new Bottom(); // we HAVE a bottom object
Right *robj = bobj; // robj point to bobj?
robj->rdisplay(); // display what ?
void *vobj = bobj; // we have a VOID* pointer
robj = (Right*) vobj; // convert it back
robj->rdisplay(); // display what?

这里的输出结果是什么呢?:

Right::rdisplay
Bottom::ldisplay // !!!!

由void*转回来的robj调用rdisplay时,却调用了莫名其妙的Bottom::ldisplay!

多重继承类的内存布局

类对象的内存布局,并不属于C++标准。这里仅以vs2005为例。上面例子中,Bottom类的内存布局大概如下:

+-------------+
| Left_vptr   |
+-------------+
| Left data   |
+-------------+
| Right_vptr  |
+-------------+
| Right data  |
+-------------+
| Bottom data |
+-------------+

与单继承不同的是,多重继承的类里,可能会包含多个vptr。当一个Bottom对象被构造好时,其内部的两个vptr也被正确初始化,其指向的vtable分别为:

Left_vptr --->  +---------------------+
                | 0: Bottom::ldisplay |
                +---------------------+

Right_vptr ---> +---------------------+
                | 0: Right::rdisplay  |
                +---------------------+

转换的内幕

类体系间的转换

隐式转换相比强制转换而言,一定算是优美的代码。考虑如下代码的输出:

Bottom *bobj = new Bottom();
printf ("%p\n", bobj);
Right *robj = bobj;
printf ("%p\n", robj);

其输出结果可能为:

003B5DA0
003B5DA4

结论就是,Right *robj = bobj;时,编译器返回了bobj的一个偏移地址。 从语言角度看,就是这个转换,返回了bobj中Right*的那一部分的起始地址。但编译器并不总是在bobj上加一个偏移,例如:

bobj = NULL;
Right *robj = bobj;

编译器不会傻到给你一个0x00000004的地址,这简直比NULL更无理。

void*转换

编译器当然有理由做上面的偏移转换。那是因为在编译阶段,编译器就知道bobj和Right之间的关系。这个偏移量甚至不需要在运行期间动态计算,或是从某个地方取。如果你看过上面代码对应的汇编指令,直接就是:

add eax, 4 ; 直接加 sizeof(Left),记住,Right在Left之后

void*就没那么幸运了。void*和Bottom没有任何关系,所以:

void *vobj = bobj; // vobj的地址和bobj完全相同

然后当你将vobj转换到一个Right*使用时:

robj = (Right*) vobj;  // 没有偏移转换,robj == vobj == bobj
robj->rdisplay();

robj指向的是Bottom的起始地址,天啊,在我们学习C++时,我们可以说Bottom就是一个Left,也是一个Right,所谓的is kind of。但这里的悲剧在于,按照上面的逻辑,我们在使用Right时,其实应该使用Bottom里Right那一部分。 但现在这个转换,却让robj指向了Bottom里Left那一部分。

当调用 robj->rdisplay 时,编译器当然按照Right的内存布局,生成一个虚函数的调用指令,大概就是:

mov vptr, robj->[0] ;; vptr在robj起始地址处
mov eax, vptr[0] ;; rdisplay在vtable中位于第一个
mov ecx, robj
call eax

总而言之, robj->rdisplay 就是使用偏移0处的值作为vptr,然后使用vptr指向的vtable中第一个函数作为调用。

但,robj正指向bobj的起始地址,这个地址是放置Left_vptr的地方。这个过程,使用了Left_ptr,而Left_ptr指向的vtable中,第一个函数是什么呢?:

Left_vptr --->  +---------------------+
                | 0: Bottom::ldisplay |
                +---------------------+

正是Bottom::ldisplay!到这里,整个问题的原因就被梳理出来了。

;;END;;

posted on 2011-04-30 20:14 Kevin Lynx 閱讀(5388) 評論(12)  編輯 收藏 引用 所屬分類: c/c++

評論

# re: 多重繼承和void*的糗事 2011-04-30 20:35 飯中淹

多重繼承真的是個很大的坑。
要小心翼翼的通過。
我以前也是和你一樣的用VOID*的時候出了這個問題。  回復(fù)  更多評論   

# re: 多重繼承和void*的糗事 2011-04-30 23:05 so

不錯,確實由于Right *robj = bobj;
編譯器做了地址調(diào)整,使之執(zhí)行如期望。  回復(fù)  更多評論   

# re: 多重繼承和void*的糗事 2011-05-01 13:38 dutor

罪魁禍首應(yīng)該是強制轉(zhuǎn)換,“丟失”了類型信息。
另外,把robj = (Right*) vobj; 換成robj = (Bottom*) vobj; 后,“在這個例子”中,編譯器還是會進行隱式轉(zhuǎn)化的吧。但對于單繼承自Right的對象來說,更詭異的事情就發(fā)生了……  回復(fù)  更多評論   

# re: 多重繼承和void*的糗事 2011-05-01 14:40 lin_style

為啥不統(tǒng)一用基地址+偏移量的方式訪問呢? 不管怎么轉(zhuǎn),地址都保持不變,根據(jù)要訪問的變量,算出偏移地址。  回復(fù)  更多評論   

# re: 多重繼承和void*的糗事 2011-05-01 17:34 Kevin Lynx

@dutor
正解。robj = (Bottom*) vobj;會做偏移。如果Bottom單繼承自Right,會出什么詭異問題?

@lin_style
如果這樣做,就等同于用匯編去操作vptr。  回復(fù)  更多評論   

# re: 多重繼承和void*的糗事 2011-05-01 17:50 lin_style

@Kevin Lynx
一樣的。比如 p->x, 匯編語言也是對p的地址加上x的偏移量。既然如此,為什么不直接統(tǒng)一一個基類地址呢?  回復(fù)  更多評論   

# re: 多重繼承和void*的糗事 2011-05-01 18:43 Kevin Lynx

@lin_style
沒完全懂你意思。是討論使用方法?還是討論底層實現(xiàn)?  回復(fù)  更多評論   

# re: 多重繼承和void*的糗事 2011-05-01 19:04 千暮(zblc)

留爪~  回復(fù)  更多評論   

# re: 多重繼承和void*的糗事[未登錄] 2011-05-02 11:14 chentan

用實現(xiàn)編譯器的思維去考慮這個問題就很好理解,但陷阱還是太多,C++就是這樣,躲陷阱都躲不過來,哪還有時間思考要其他問題,有限度的使用C++特性吧  回復(fù)  更多評論   

# re: 多重繼承和void*的糗事 2011-05-05 10:17 lin_style

為什么編譯器不直接看成是單繼承呢??  回復(fù)  更多評論   

# re: 多重繼承和void*的糗事 2011-05-05 10:20 lin_style

@lin_style
明白了,白問了。   回復(fù)  更多評論   

# re: 多重繼承和void*的糗事 2011-06-01 14:48 cyg07

:) 這東西本來就是自然的。
都到 void* 這里了還想著它擁有原來的類型可以讓后面的強轉(zhuǎn)給搞定?

帖中和下面是相等的:
robj = (Right*)( (void*)boji ); // convert it back
很和諧的讓你過去了,木哈哈。
robj = dynamic_cast<Right*>( (void*)bobj ); // convert it back
C++的編譯時檢測會讓你通過么?

也許更關(guān)鍵的問題是我們在用C的時候總是站在C++的角度,void*的使用一般需要另外的一個可靠的類型標記來做依托的。也許更多的時候會覺得C++的法則是狗屁。

robj = (Right*)boji;
在C的編譯器里能支持這個?
C都沒有繼承,連詞法檢測的時候都會過不去的阿?
也許最原始的問題在于C++莫名的把C的強制轉(zhuǎn)換范圍給擴大了,它干么要讓你能用C的強制轉(zhuǎn)換直接轉(zhuǎn)上下層關(guān)系呢?CPP是不是又該加入一條標準讓編譯器必須對此XXOO?厄,歸根到底是C++還想依靠C過日子,有木有?
  回復(fù)  更多評論   

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            先锋影院在线亚洲| 亚洲深爱激情| 亚洲人成人99网站| 久久精品国产亚洲aⅴ| 99精品国产福利在线观看免费| 美女在线一区二区| 老巨人导航500精品| 蜜乳av另类精品一区二区| 久久精品国产999大香线蕉| 欧美在线观看视频在线| 久久国产免费| 狂野欧美激情性xxxx欧美| 老司机精品视频一区二区三区| 久久久久综合网| 亚洲私人影院在线观看| 亚洲性夜色噜噜噜7777| 亚洲欧美日韩视频二区| 久久国产精品电影| 免费在线成人av| 99国产精品国产精品久久| 亚洲自拍偷拍视频| 久久综合久久综合久久综合| 欧美国产日韩亚洲一区| 国产精品成人av性教育| 欧美一级欧美一级在线播放| 国产精品一区视频| 欧美伊人久久| 欧美日韩亚洲不卡| 亚洲自拍高清| 亚洲免费一区二区| 女仆av观看一区| 亚洲一区国产一区| 久久久青草青青国产亚洲免观| 欧美日本韩国一区| 欧美一区二区免费观在线| 久久久久国产精品一区| 亚洲成人中文| 亚洲人成人一区二区在线观看| 亚洲国产精品va在线看黑人动漫| 欧美成人激情视频| 国产一级精品aaaaa看| 99视频一区二区三区| 久久久久国产精品厨房| avtt综合网| 欧美激情 亚洲a∨综合| 国内外成人在线| 亚洲伊人观看| 亚洲精品久久久久久久久久久久久 | 一本久道久久久| 久久天天躁夜夜躁狠狠躁2022 | 亚洲高清在线观看| 欧美一区成人| 一区二区三区视频在线看| 免费在线观看一区二区| 国产亚洲欧美日韩美女| 亚洲一区精品视频| 91久久精品国产91性色| 亚洲国产欧美日韩另类综合| 欧美va亚洲va香蕉在线| 亚洲女爱视频在线| 香蕉亚洲视频| 蜜臀91精品一区二区三区| 亚洲午夜视频| 亚洲剧情一区二区| 国产午夜精品一区理论片飘花| 日韩一区二区精品视频| 亚洲国产精品久久久久婷婷老年| 亚洲精品免费在线播放| 久久综合精品国产一区二区三区| 欧美国产日韩一区二区三区| 国产日韩综合一区二区性色av| 欧美福利专区| 好看的日韩视频| 欧美专区18| 亚洲色诱最新| 国产精品国产一区二区| 亚洲老板91色精品久久| 欧美成人精品h版在线观看| 欧美一区二区三区四区在线观看| 亚洲女同在线| 国产毛片精品国产一区二区三区| 一区二区日韩免费看| 亚洲国产成人在线| 嫩草国产精品入口| 亚洲美女中出| 国产精品xxxxx| 日韩午夜电影| 欧美sm视频| 欧美日韩一区二区三区在线观看免| 91久久精品日日躁夜夜躁欧美 | 亚洲午夜av电影| 99re6热只有精品免费观看| 国产精品免费看久久久香蕉| 亚洲一区二区在| 久久国产欧美日韩精品| 黄色欧美日韩| 在线播放中文一区| 亚洲国产欧美一区二区三区同亚洲| 欧美freesex交免费视频| 亚洲精品视频在线看| 免费成人黄色av| 欧美精品手机在线| 91久久精品网| 久久狠狠亚洲综合| 激情综合五月天| 在线视频日本亚洲性| 免费成人在线观看视频| 欧美日本高清| 久久久蜜桃精品| 欧美日韩国产综合视频在线观看 | 欧美色视频日本高清在线观看| 宅男噜噜噜66一区二区| 制服丝袜亚洲播放| 国产原创一区二区| 国产精品看片资源| 久久丁香综合五月国产三级网站| 久久精品91久久香蕉加勒比| 亚洲激情电影中文字幕| 亚洲午夜激情网站| 国产亚洲欧洲997久久综合| 亚洲国产经典视频| 国产女精品视频网站免费| 亚洲国产专区| 国内自拍一区| 西西裸体人体做爰大胆久久久| 亚洲精品中文字幕有码专区| 久久精品亚洲| 欧美一级午夜免费电影| 欧美裸体一区二区三区| 久久亚洲春色中文字幕| 欧美凹凸一区二区三区视频| 国产日产欧美一区| 欧美成年网站| 有码中文亚洲精品| 亚洲精品国产精品国自产观看浪潮| 久久婷婷国产综合国色天香| 亚洲欧美日韩国产成人精品影院| 日韩一级二级三级| 久久免费视频观看| 久久综合电影| 国产日韩在线一区| 欧美一区二区三区四区视频| 亚洲欧美日韩在线高清直播| 欧美日韩综合视频| 亚洲伦理精品| 亚洲中午字幕| 欧美日韩综合精品| 亚洲在线网站| 中文成人激情娱乐网| 国产精品成人国产乱一区| 亚洲欧洲精品一区二区三区 | 久久av一区二区三区漫画| 亚洲欧美日韩国产| 国产日韩精品综合网站| 亚洲视频狠狠| 久久久久国产精品www| 国产精品青草久久久久福利99| 亚洲天堂av在线免费| 一区二区三区四区国产| 国产精品国产精品国产专区不蜜| 日韩视频一区| 欧美伊人久久久久久午夜久久久久| 国产精品成人免费视频 | 久久国产精品黑丝| 毛片一区二区三区| 黄网动漫久久久| 欧美精品一区二区三区在线播放 | 99国产精品自拍| 亚洲欧美精品在线| 国产精品一区二区久久久久 | 另类av导航| 亚洲人成人99网站| 欧美理论在线| 羞羞视频在线观看欧美| 久久久999| 亚洲精品视频中文字幕| 欧美日韩1区2区| 久久精品99| 母乳一区在线观看| 亚洲欧美日韩综合| 欧美日产一区二区三区在线观看 | 噜噜噜91成人网| 亚洲国产精品一区在线观看不卡| 欧美日韩三级| 午夜亚洲性色福利视频| 亚洲国产视频直播| 亚洲女人av| 国产在线精品成人一区二区三区| 久久一区视频| 日韩午夜电影av| 在线日韩日本国产亚洲| 欧美日韩爆操| 国内精品久久久久久影视8| 久久不射中文字幕| 亚洲风情亚aⅴ在线发布| 久久久久成人精品| 亚洲精品国产精品国自产观看| 国产一区二区三区四区五区美女 | 国产视频久久久久| 欧美国产日韩在线|