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

大龍的博客

常用鏈接

統(tǒng)計(jì)

最新評論

extern "C"(轉(zhuǎn)個(gè)好帖,解釋的夠透徹)

通常,在C語言的頭文件中經(jīng)常可以看到類似下面這種形式的代碼:

#ifdef __cplusplus
extern "C" {
#endif

/**** some declaration or so *****/

#ifdef __cplusplus
}

#endif /* end of __cplusplus */

那么,這種寫法什么用呢?實(shí)際上,這是為了CPP能夠與C接口而采用的一種語法形式。之所以采用這種方式,是因?yàn)閮煞N語言之間的一些差異所導(dǎo)致的。由于CPP支持多態(tài)性,也就是具有相同函數(shù)名的函數(shù)可以完成同的功能,CPP通常是通過參數(shù)區(qū)分具體調(diào)用的是哪一個(gè)函數(shù)。在編譯的時(shí)候,CPP編譯器會(huì)將參數(shù)類型和函數(shù)名連接在一起,于是在程序編譯成為目標(biāo)文件以后,CPP編譯器可以直接根據(jù)目標(biāo)文件中的符號名將多個(gè)目標(biāo)文件連接成一個(gè)目標(biāo)文件或者可執(zhí)行文件。但是在C語言中,由于完全沒有多態(tài)性的概念,C編譯器在編譯時(shí)除了會(huì)在函數(shù)名前面添加一個(gè)下劃線之外,什么也會(huì)做(至少很多編譯器都是這樣干的)。由于這種的原因,當(dāng)采用CPP與C混合編程的時(shí)候,就可能會(huì)出問題。假設(shè)在某一個(gè)頭文件中定義了這樣一個(gè)函數(shù):

int foo(int a, int b);


而這個(gè)函數(shù)的實(shí)現(xiàn)位于一個(gè).c文件中,同時(shí),在.cpp文件中調(diào)用了這個(gè)函數(shù)。那么,當(dāng)CPP編譯器編譯這個(gè)函數(shù)的時(shí)候,就有可能會(huì)把這個(gè)函數(shù)名成_fooii,這里的ii表示函數(shù)的第一參數(shù)和第二參數(shù)都是整型。而C編譯器卻有可能將這個(gè)函數(shù)名編譯成_foo。也就是說,在CPP編譯器得到的目標(biāo)文件中,foo()函數(shù)是由_fooii符號來引用的,而在C編譯器生成的目標(biāo)文件中,foo()函數(shù)是由_foo指代的。但連接器工作的時(shí)候,它可管上層采用的是什么語言,它只認(rèn)目標(biāo)文件中的符號。于是,連接器將會(huì)發(fā)現(xiàn)在.cpp中調(diào)用了foo()函數(shù),但是在其它的目標(biāo)文件中卻找到_fooii這個(gè)符號,于是提示連接過程出錯(cuò)。extern "C" {}這種語法形式就是用來解決這個(gè)問題的。本文將以示例對這個(gè)問題進(jìn)行說明。

首先假設(shè)有下面這樣三個(gè)文件:

/* file: test_extern_c.h */
#ifndef __TEST_EXTERN_C_H__
#define __TEST_EXTERN_C_H__
#ifdef __cplusplus
extern "C" {
#endif
/*
* this is a test function, which calculate
* the multiply of a and b.
*/

extern int ThisIsTest(int a, int b);
#ifdef __cplusplus
}


#endif /* end of __cplusplus */
#endif


在這個(gè)頭文件中只定義了一個(gè)函數(shù),ThisIsTest()。這個(gè)函數(shù)被定義為一個(gè)外部函數(shù),可以被包括到其它程序文件中。假設(shè)ThisIsTest()函數(shù)的實(shí)現(xiàn)位于test_extern_c.c文件中:
/* test_extern_c.c */

#include "test_extern_c.h"
int ThisIsTest(int a, int b)
{
return (a + b);
}


可以看到,ThisIsTest()函數(shù)的實(shí)現(xiàn)非常簡單,就是將兩個(gè)參數(shù)的相加結(jié)果返回而已。現(xiàn)在,假設(shè)要從CPP中調(diào)用ThisIsTest()函數(shù):

/* main.cpp */

#include "test_extern_c.h"
#include <stdio.h>
#include <stdlib.h>
class FOO {
public:
int bar(int a, int b)
{
printf("result=%i\n", ThisIsTest(a, b));
}
};

int main(int argc, char **argv)
{
int a = atoi(argv[1]);
int b = atoi(argv[2]);
FOO *foo = new FOO();

foo->bar(a, b);
return(0);
}

在這個(gè)CPP源文件中,定義了一個(gè)簡單的類FOO,在其成員函數(shù)bar()中調(diào)用了ThisIsTest()函數(shù)。下面看一下如果采用gcc編譯test_extern_c.c,而采用g++編譯main.cpp并與test_extern_c.o連接會(huì)發(fā)生什么情況:

[cyc@cyc src]$ gcc -c test_extern_c.c
[cyc@cyc src]$ g++ main.cpp test_extern_c.o
[cyc@cyc src]$ ./a.out 4 5
result=9

可以看到,程序沒有任何異常,完全按照預(yù)期的方式工作。那么,如果將test_extern_c.h中的extern "C" {}所在的那幾行注釋掉會(huì)怎樣呢?注釋后的test_extern_c.h文件內(nèi)容如下:

/* test_extern_c.h */

#ifndef __TEST_EXTERN_C_H__
#define __TEST_EXTERN_C_H__
//#ifdef __cplusplus
//extern "C" {
//#endif
/*
/* this is a test function, which calculate
* the multiply of a and b.
*/
extern int ThisIsTest(int a, int b);
//#ifdef __cplusplus
// }
//#endif /* end of __cplusplus */
#endif


之外,其它文件做任何的變,仍然采用同樣的方式編譯test_extern_c.c和main.cpp文件:

[cyc@cyc src]$ gcc -c test_extern_c.c
[cyc@cyc src]$ g++ main.cpp test_extern_c.o

/tmp/cca4EtJJ.o(.gnu.linkonce.t._ZN3FOO3barEii+0x10): In function `FOO::bar(int, int)':
: undefined reference to `ThisIsTest(int, int)'
collect2: ld returned 1 exit status

在編譯main.cpp的時(shí)候就會(huì)出錯(cuò),連接器ld提示找到對函數(shù)ThisIsTest()的引用。

為了更清楚地說明問題的原因,我們采用下面的方式先把目標(biāo)文件編譯出來,然后看目標(biāo)文件中到底都有些什么符號:

[cyc@cyc src]$ gcc -c test_extern_c.c
[cyc@cyc src]$ objdump -t test_extern_c.o

test_extern_c.o: file format elf32-i386
SYMBOL TABLE:
00000000 l df *ABS* 00000000 test_extern_c.c
00000000 l d .text 00000000
00000000 l d .data 00000000
00000000 l d .bss 00000000
00000000 l d .comment 00000000
00000000 g F .text 0000000b ThisIsTest

[cyc@cyc src]$ g++ -c main.cpp
[cyc@cyc src]$ objdump -t main.o

main.o: file format elf32-i386

MYMBOL TABLE:

00000000 l df *ABS* 00000000 main.cpp
00000000 l d .text 00000000
00000000 l d .data 00000000
00000000 l d .bss 00000000
00000000 l d .rodata 00000000
00000000 l d .gnu.linkonce.t._ZN3FOO3barEii 00000000
00000000 l d .eh_frame 00000000
00000000 l d .comment 00000000
00000000 g F .text 00000081 main
00000000 *UND* 00000000 atoi
00000000 *UND* 00000000 _Znwj
00000000 *UND* 00000000 _ZdlPv
00000000 w F .gnu.linkonce.t._ZN3FOO3barEii 00000027 _ZN3FOO3barEii
00000000 *UND* 00000000 _Z10ThisIsTestii
00000000 *UND* 00000000 printf
00000000 *UND* 00000000 __gxx_personality_v0

可以看到,采用gcc編譯了test_extern_c.c之后,在其目標(biāo)文件test_extern_c.o中的有一個(gè)ThisIsTest符號,這個(gè)符號就是源文件中定義的ThisIsTest()函數(shù)了。而在采用g++編譯了main.cpp之后,在其目標(biāo)文件main.o中有一個(gè)_Z10ThisIsTestii符號,這個(gè)就是經(jīng)過g++編譯器“粉碎”過后的函數(shù)名。其最后的兩個(gè)字符i就表示第一參數(shù)和第二參數(shù)都是整型。而為什么要加一個(gè)前綴_Z10我并清楚,但這里并影響我們的討論,因此去管它。顯然,這就是原因的所在,其原理在本文開頭已作了說明。

那么,為什么采用了extern "C" {}形式就會(huì)有這個(gè)問題呢,我們就來看一下當(dāng)test_extern_c.h采用extern "C" {}的形式時(shí)編譯出來的目標(biāo)文件中又有哪些符號:

[cyc@cyc src]$ gcc -c test_extern_c.c

[cyc@cyc src]$ objdump -t test_extern_c.o

test_extern_c.o: file format elf32-i386

SYMBOL TABLE:
00000000 l df *ABS* 00000000 test_extern_c.c
00000000 l d .text 00000000
00000000 l d .data 00000000
00000000 l d .bss 00000000
00000000 l d .comment 00000000
00000000 g F .text 0000000b ThisIsTest

[cyc@cyc src]$ g++ -c main.cpp
[cyc@cyc src]$ objdump -t main.o
main.o: file format elf32-i386
SYMBOL TABLE:

00000000 l df *ABS* 00000000 main.cpp
00000000 l d .text 00000000
00000000 l d .data 00000000
00000000 l d .bss 00000000
00000000 l d .rodata 00000000
00000000 l d .gnu.linkonce.t._ZN3FOO3barEii 00000000
00000000 l d .eh_frame 00000000
00000000 l d .comment 00000000
00000000 g F .text 00000081 main
00000000 *UND* 00000000 atoi
00000000 *UND* 00000000 _Znwj
00000000 *UND* 00000000 _ZdlPv
00000000 w F .gnu.linkonce.t._ZN3FOO3barEii 00000027 _ZN3FOO3barEii
00000000 *UND* 00000000 ThisIsTest
00000000 *UND* 00000000 printf
00000000 *UND* 00000000 __gxx_personality_v0

注意到這里和前面有什么同沒有,可以看到,在兩個(gè)目標(biāo)文件中,都有一個(gè)符號ThisIsTest,這個(gè)符號引用的就是ThisIsTest()函數(shù)了。顯然,此時(shí)在兩個(gè)目標(biāo)文件中都存在同樣的ThisIsTest符號,因此認(rèn)為它們引用的實(shí)際上同一個(gè)函數(shù),于是就將兩個(gè)目標(biāo)文件連接在一起,凡是出現(xiàn)程序代碼段中有ThisIsTest符號的地方都用ThisIsTest()函數(shù)的實(shí)際地址代替。另外,還可以看到,僅僅被extern "C" {}包圍起來的函數(shù)采用這樣的目標(biāo)符號形式,對于main.cpp中的FOO類的成員函數(shù),在兩種編譯方式后的符號名都是經(jīng)過“粉碎”了的。

因此,綜合上面的分析,我們可以得出如下結(jié)論:采用extern "C" {} 這種形式的聲明,可以使得CPP與C之間的接口具有互通性,會(huì)由于語言內(nèi)部的機(jī)制導(dǎo)致連接目標(biāo)文件的時(shí)候出現(xiàn)錯(cuò)誤。需要說明的是,上面只是根據(jù)我的試驗(yàn)結(jié)果而得出的結(jié)論。由于對于CPP用得是很多,了解得也很少,因此對其內(nèi)部處理機(jī)制并是很清楚,如果需要深入了解這個(gè)問題的細(xì)節(jié)請參考相關(guān)資料。

posted on 2009-05-26 14:22 大龍 閱讀(273) 評論(0)  編輯 收藏 引用


只有注冊用戶登錄后才能發(fā)表評論。
網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            欧美大片免费观看在线观看网站推荐| 羞羞漫画18久久大片| 欧美特黄a级高清免费大片a级| 亚洲欧洲av一区二区三区久久| 欧美女激情福利| 99re亚洲国产精品| 亚洲美女精品成人在线视频| 欧美成人免费网站| 久久综合久色欧美综合狠狠| 免费在线观看精品| 欧美大片在线观看一区二区| 久久一区二区视频| 亚洲欧洲偷拍精品| 亚洲精品免费观看| 亚洲一区二区三区涩| 亚洲欧美大片| 欧美国产欧美亚州国产日韩mv天天看完整| 亚洲视频一区在线| 亚洲欧美激情一区| 欧美国产日韩一区二区三区| 欧美精品一区二区三区一线天视频 | 一本色道久久88亚洲综合88| 亚洲毛片在线看| 久久本道综合色狠狠五月| 亚洲激情另类| 久久精品国产精品亚洲综合| 欧美伦理一区二区| 亚洲国产经典视频| 欧美成人自拍视频| 国产欧美日韩亚洲| 国产农村妇女精品| 夜夜嗨av一区二区三区| 久久夜色精品国产欧美乱| 99精品热视频| 欧美精品v日韩精品v韩国精品v| 国产日本欧美一区二区三区| 亚洲手机成人高清视频| 亚洲国产精品久久久久秋霞影院| 午夜欧美不卡精品aaaaa| 国产精品家教| 久久久亚洲一区| 毛片一区二区三区| 91久久夜色精品国产网站| 欧美黄色一级视频| 一区二区欧美视频| 亚洲精品久久久久久久久| 欧美自拍偷拍午夜视频| 欧美一级免费视频| 激情五月婷婷综合| 欧美激情中文字幕在线| 欧美成人精品不卡视频在线观看| 亚洲全部视频| 亚洲破处大片| 国产精品美腿一区在线看| 久久亚洲美女| 欧美色播在线播放| 久久综合精品一区| 欧美韩国日本一区| 久久se精品一区精品二区| 91久久精品国产91性色| 99在线精品视频| 校园春色国产精品| 一区二区精品在线观看| 这里只有精品丝袜| 欧美日韩免费观看一区=区三区| 欧美精品在线一区二区| 亚洲精品视频在线观看网站| 亚洲一区免费看| 亚洲精品久久7777| 欧美一区二区私人影院日本| 在线综合亚洲| 鲁大师影院一区二区三区| 午夜欧美大片免费观看| 你懂的视频一区二区| 99re66热这里只有精品4| av成人手机在线| 日韩一级网站| 欧美mv日韩mv国产网站app| 久久国产精品网站| 国产精品久久久久久久久久免费 | 亚洲免费在线播放| 一本不卡影院| 欧美日韩午夜在线| 亚洲午夜羞羞片| 欧美一级视频一区二区| 国产精品一区免费在线观看| 亚洲视屏一区| 猫咪成人在线观看| 免费亚洲视频| 欧美日韩专区在线| 久久露脸国产精品| 亚洲一区二区三区免费在线观看 | 欧美一级片一区| 国产精品日韩电影| 免费观看日韩av| 久久久久久久一区| 欧美专区在线播放| 久久国产精品99精品国产| 午夜亚洲激情| 久久黄金**| 老牛影视一区二区三区| 久久久久久久综合日本| 久久精品国产亚洲a| 久久riav二区三区| 玖玖玖免费嫩草在线影院一区| 久久久久国产精品午夜一区| 欧美日本韩国一区| 亚洲午夜久久久| 欧美一区三区三区高中清蜜桃 | 亚洲欧洲免费视频| 夜夜嗨av一区二区三区中文字幕| 亚洲美女精品成人在线视频| 99热这里只有成人精品国产| 欧美一二三视频| 欧美成人首页| 亚洲综合精品四区| 久久亚洲一区二区| 国产精品色一区二区三区| 在线国产亚洲欧美| 亚洲综合日韩中文字幕v在线| 老牛嫩草一区二区三区日本| 亚洲人体1000| 久久国内精品自在自线400部| 欧美日本一区| 亚洲激情网站| 久久久久青草大香线综合精品| 亚洲欧洲日韩在线| 久久久久久91香蕉国产| 国产精品视频99| 亚洲天堂av综合网| 一区二区成人精品 | 亚洲一本大道在线| 久久狠狠一本精品综合网| 国产精品美女主播| 性欧美videos另类喷潮| 久久精品人人做人人爽电影蜜月| 欧美精品播放| 亚洲国产精品一区二区www在线| 亚洲欧美怡红院| 亚洲在线1234| 国产乱码精品一区二区三区五月婷| 91久久精品国产91性色| 另类av导航| 欧美一级免费视频| 亚洲国产精品免费| 亚洲国产精品一区二区尤物区| 亚洲视频一区二区| 欧美特黄视频| 亚洲一区欧美| 亚洲一区免费观看| 国产亚洲一区精品| 久久先锋影音| 久久精品人人做人人综合| 国产一区二区三区久久悠悠色av| 国产亚洲综合性久久久影院| 一级日韩一区在线观看| 亚洲精品老司机| 欧美日韩系列| 久久精品一区二区三区四区| 午夜亚洲精品| 亚洲精品欧美极品| 性色一区二区| 亚洲一区二区在线播放| 久久久久久综合| 99综合在线| 日韩亚洲国产精品| 亚洲国产精品第一区二区三区| 一区二区三区视频在线观看| 精品成人在线| 欧美在线免费视屏| 亚洲午夜av电影| 久久久久国产精品www| 亚洲欧美日韩国产另类专区| 农夫在线精品视频免费观看| 亚洲欧美在线aaa| 久久精品国产欧美激情| 久久精品99国产精品| 激情五月***国产精品| 国产精品久久久91| 亚洲永久免费精品| 亚洲一区www| 欧美日韩久久| 亚洲香蕉在线观看| 亚洲天堂av在线免费观看| 久久久五月婷婷| 久久综合亚洲社区| 在线观看亚洲精品视频| 欧美成人精品一区二区| 模特精品裸拍一区| 亚洲精品乱码久久久久久久久| 久久综合九色九九| 亚洲国产日韩欧美| 你懂的一区二区| aⅴ色国产欧美| 亚洲男女毛片无遮挡| 国产精品亚洲片夜色在线| 欧美在线视频观看| 亚洲国产欧美久久| 一本大道av伊人久久综合| 欧美a级片网|