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

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>
            亚洲国产另类久久精品| 欧美在线视频观看免费网站| 欧美国产精品va在线观看| 中文亚洲欧美| 亚洲影视在线| 欧美亚洲一级片| 久久婷婷国产综合国色天香| 欧美第一黄网免费网站| 亚洲人体偷拍| 亚洲视频在线一区| 销魂美女一区二区三区视频在线| 亚洲一区美女视频在线观看免费| 香蕉久久夜色精品| 免费h精品视频在线播放| 欧美日本一区二区视频在线观看| 国产精品日韩欧美| 亚洲第一精品在线| 亚洲私人影院| 猛干欧美女孩| 日韩一级精品视频在线观看| 欧美一区二区三区啪啪 | 99在线精品观看| 亚洲小视频在线观看| 久久成人免费| 欧美三级视频在线观看| 国内在线观看一区二区三区 | 国产精品xvideos88| 韩国在线一区| 在线亚洲国产精品网站| 麻豆国产精品777777在线| 亚洲乱码久久| 久久久人成影片一区二区三区观看 | 校园激情久久| 欧美日韩成人| 在线观看免费视频综合| 亚洲欧美综合一区| 亚洲日韩第九十九页| 久久精品二区三区| 国产精品久久一级| 一本久久知道综合久久| 欧美成人中文字幕在线| 午夜精品久久久久久久蜜桃app | 一二三区精品| 欧美电影免费观看高清| 国产一区二区三区直播精品电影| 在线视频你懂得一区 | 久久久免费av| 狠狠v欧美v日韩v亚洲ⅴ| 亚洲欧美制服另类日韩| 99视频精品全部免费在线| 欧美亚洲视频一区二区| 一区二区三区回区在观看免费视频| 麻豆乱码国产一区二区三区| 亚洲欧美一区二区三区在线| 欧美日韩在线视频观看| 日韩一级大片| 亚洲乱码国产乱码精品精| 欧美激情精品久久久六区热门| 一区二区三区在线看| 老牛影视一区二区三区| 久久久欧美精品| 亚洲国产精品va在线看黑人动漫| 久久亚洲欧洲| 牛人盗摄一区二区三区视频| 亚洲激情av在线| 亚洲精品视频一区| 欧美特黄a级高清免费大片a级| 在线中文字幕一区| 亚洲一区二区三区午夜| 国产欧美日韩高清| 久久婷婷影院| 欧美.com| 一区二区三区四区国产精品| 夜夜嗨av一区二区三区| 国产精品美女午夜av| 久久精品99| 美女视频一区免费观看| 99精品国产一区二区青青牛奶| 亚洲精品一区中文| 国产精品国产三级国产| 久久米奇亚洲| 欧美日本视频在线| 久久精品成人欧美大片古装| 免费视频亚洲| 亚洲综合精品四区| 久久久久久久综合日本| 99精品视频免费观看视频| 亚洲特级片在线| 一区二区在线观看av| 亚洲日本精品国产第一区| 国产精品―色哟哟| 欧美 日韩 国产在线| 欧美小视频在线观看| 麻豆久久精品| 国产精品欧美一区二区三区奶水 | 亚洲精品中文字幕在线观看| 国产精品成人午夜| 久久人人爽爽爽人久久久| 欧美日本一道本| 久久伊人免费视频| 欧美日韩在线精品| 久久久7777| 欧美三级乱人伦电影| 久久婷婷国产综合国色天香| 欧美手机在线| 亚洲电影免费在线观看| 国产精品日本一区二区| 亚洲电影视频在线| 国产午夜精品视频| 日韩午夜av在线| 亚洲午夜小视频| 久久精品国产69国产精品亚洲| 日韩一级精品| 久久久亚洲精品一区二区三区 | 欧美成人午夜激情在线| 国产精品免费看| 亚洲精品网站在线播放gif| 在线日韩欧美视频| 欧美亚洲一区二区三区| 亚洲欧美国产va在线影院| 欧美精品一区二| 欧美国产日本在线| 黄色av成人| 欧美在线不卡视频| 性欧美长视频| 欧美日韩综合一区| 亚洲精品男同| 日韩视频在线你懂得| 久久亚洲精品网站| 麻豆成人小视频| 在线观看国产日韩| 久久久久久综合| 久久综合一区| 在线欧美日韩精品| 免费观看成人| 亚洲精品国产精品国自产观看| 亚洲国产精品热久久| 久久久欧美一区二区| 欧美a级一区二区| 亚洲大胆人体在线| 免费不卡视频| 亚洲欧洲一区| 亚洲欧美国产另类| 国产欧美精品一区二区色综合 | 亚洲视频在线看| 欧美日韩高清在线播放| 亚洲美女av黄| 午夜精品久久久久| 国产精品亚发布| 欧美在线精品一区| 免费观看亚洲视频大全| 亚洲电影有码| 欧美日韩精品一区二区| 久久久久国色av免费观看性色| 国产伦精品一区二区三区视频黑人 | 一区二区三区精品视频| 亚洲综合视频在线| 国产深夜精品| 免费日韩视频| 一区二区三区蜜桃网| 久久riav二区三区| 91久久精品国产91性色| 欧美精品二区| 亚洲一区高清| 欧美二区不卡| 亚洲影院色在线观看免费| 国产综合色产在线精品| 久久天天躁狠狠躁夜夜av| 久久久噜噜噜| 亚洲国产一区二区三区青草影视| 亚洲最新视频在线| 国产伦精品一区二区三区免费迷 | 国产日韩精品在线播放| 久久三级福利| 一区二区三区高清在线| 美女主播一区| 午夜欧美精品| 亚洲国产综合视频在线观看| 国产精品久久久| 久久九九热免费视频| 一区二区三区|亚洲午夜| 蜜桃精品久久久久久久免费影院| 一区二区三区高清| 一区二区三区在线视频观看| 欧美午夜精品久久久久久久| 另类亚洲自拍| 欧美在线观看一区| 亚洲自拍16p| 亚洲人成绝费网站色www| 久久夜色精品亚洲噜噜国产mv| 亚洲一区精品电影| 亚洲国产日韩欧美在线99 | 一二三区精品| 亚洲丁香婷深爱综合| 久久精品一区二区三区中文字幕| 一区二区冒白浆视频| 精品成人一区二区| 国产日韩av一区二区| 国产精品久久一卡二卡| 欧美日韩性视频在线|