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

loop_in_codes

低調做技術__歡迎移步我的獨立博客 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*的時候出了這個問題。  回復  更多評論   

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

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

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

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

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

為啥不統一用基地址+偏移量的方式訪問呢? 不管怎么轉,地址都保持不變,根據要訪問的變量,算出偏移地址。  回復  更多評論   

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

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

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

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

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

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

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

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

留爪~  回復  更多評論   

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

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

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

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

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

@lin_style
明白了,白問了。   回復  更多評論   

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

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

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

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

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

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            麻豆91精品91久久久的内涵| 欧美激情1区2区| 美女性感视频久久久| 亚洲一区二区视频在线| 亚洲国产日韩在线一区模特| 国产亚洲人成a一在线v站| 国产免费成人在线视频| 欧美三级免费| 欧美性做爰猛烈叫床潮| 国产精品一级| 亚洲第一精品夜夜躁人人爽| 日韩西西人体444www| 性欧美激情精品| 欧美jizz19性欧美| 亚洲色在线视频| 欧美一区二区成人| 久久久亚洲人| 欧美日韩你懂的| 国产一区美女| 99精品国产在热久久| 亚洲欧美日韩一区二区| 久久夜色精品国产欧美乱| 亚洲黄一区二区三区| 亚洲国产精品视频| 亚洲免费中文字幕| 欧美va亚洲va国产综合| 国产精品免费一区豆花| 亚洲第一毛片| 亚洲女同精品视频| 欧美激情精品久久久久久免费印度| 99re66热这里只有精品4| 午夜在线视频一区二区区别| 欧美a一区二区| 国产日韩视频| 亚洲视频一区在线| 欧美a级片网站| 亚洲男人第一av网站| 欧美精品一区二区三区一线天视频 | 欧美伦理91i| 黄色成人免费观看| 先锋资源久久| 一区二区动漫| 欧美激情欧美激情在线五月| 国产欧美一二三区| 亚洲制服丝袜在线| 亚洲精品综合精品自拍| 裸体歌舞表演一区二区| 国产日韩欧美视频| 国产一区二区中文| 欧美少妇一区| 一区二区三区高清视频在线观看| 影音先锋久久精品| 亚洲欧美中文字幕| 99精品欧美一区| 欧美黑人在线观看| 亚洲国产影院| 欧美69视频| 久久综合久久美利坚合众国| 韩日精品视频| 久久久久久久成人| 久久国产一区二区| 黄网站免费久久| 久久综合给合| 久久夜色精品国产亚洲aⅴ| 在线成人激情| 免费毛片一区二区三区久久久| 久久精品女人天堂| 在线日韩av永久免费观看| 蜜臀va亚洲va欧美va天堂| 久久只有精品| 日韩亚洲不卡在线| 99精品热视频| 国产精品另类一区| 久久精品国产一区二区电影| 欧美一二三区精品| 尤物九九久久国产精品的特点| 你懂的成人av| 欧美精品综合| 性xx色xx综合久久久xx| 欧美一区二区三区在线看| 在线观看的日韩av| 亚洲国产欧美一区二区三区久久 | 久久福利精品| 久久久久一区二区三区四区| 亚洲激情另类| av成人天堂| 国产一区在线免费观看| 亚洲国产日韩一区| 国产精品色一区二区三区| 久久一二三四| 欧美日本一道本在线视频| 欧美一区二区三区四区在线观看地址 | 国产日韩欧美一区| 欧美激情女人20p| 国产精品theporn| 久久免费少妇高潮久久精品99| 麻豆成人小视频| 亚洲欧美国产精品专区久久| 久久人人爽人人爽爽久久| 亚洲午夜一区二区三区| 亚洲视频大全| 欧美一区二区在线播放| 久久综合九九| 性欧美暴力猛交另类hd| 免费成人在线观看视频| 午夜精品久久久久久久99樱桃| 久久伊人精品天天| 午夜久久福利| 欧美激情2020午夜免费观看| 久久久久成人精品免费播放动漫| 欧美激情在线有限公司| 久久免费偷拍视频| 欧美午夜免费| 亚洲第一在线综合网站| 国产人成一区二区三区影院| 亚洲精选在线| 亚洲精品视频在线看| 久久国产精品久久久久久久久久 | 亚洲专区欧美专区| 欧美风情在线观看| 老司机精品久久| 国产精品一区二区三区观看 | 99精品国产热久久91蜜凸| 好吊妞这里只有精品| 亚洲一区网站| 亚洲一区二区成人| 欧美日韩一区二区在线播放| 亚洲福利视频一区| 亚洲国产精品久久| 久久久久久久久久久久久9999| 欧美一区二区黄| 国产精品国产三级国产专区53| 亚洲区国产区| 日韩一级片网址| 欧美精品一区二区视频| 亚洲精品一区二区三区樱花 | 一区二区电影免费在线观看| 亚洲最新在线视频| 欧美精品色网| 日韩视频二区| 亚洲天堂av高清| 欧美日韩精品二区第二页| 91久久精品日日躁夜夜躁欧美 | 久久免费偷拍视频| 在线欧美视频| 欧美精品激情blacked18| 亚洲黄一区二区| 亚洲私拍自拍| 国产欧美69| 欧美在线关看| 欧美成人精品在线视频| 亚洲三级观看| 欧美日本不卡| 亚洲一区二区三区四区五区午夜| 性久久久久久| 亚洲国产高清视频| 欧美日韩和欧美的一区二区| 亚洲在线免费视频| 久久国产高清| 一本大道久久a久久精二百| 欧美电影在线观看完整版| 91久久精品一区| 小黄鸭精品密入口导航| 国精产品99永久一区一区| 久久在线免费观看| 日韩一级片网址| 久久精品视频va| 亚洲黄色高清| 国产精品美女| 久久中文字幕一区二区三区| 亚洲日本欧美在线| 久久精品道一区二区三区| 亚洲精品乱码| 国产日产欧产精品推荐色 | 久久国产66| 亚洲精品视频啊美女在线直播| 午夜精品在线视频| 亚洲精品乱码久久久久久黑人| 国产精品久久久久久久久久久久久 | 久久亚洲一区二区| 一区二区日韩伦理片| 好看的日韩av电影| 欧美视频不卡| 欧美va天堂| 久久久噜噜噜久噜久久| 亚洲主播在线观看| 日韩一区二区精品在线观看| 欧美国产乱视频| 久久久久88色偷偷免费| 亚洲一区二区免费看| 最新日韩av| 国内精品久久久久久久影视麻豆| 欧美午夜视频在线| 欧美护士18xxxxhd| 欧美在线视频一区二区| 亚洲一区二区黄| 99精品欧美一区二区三区综合在线| 欧美激情一区| 噜噜噜在线观看免费视频日韩| 午夜精品99久久免费|