第一種理解
比如說你用C++開發(fā)了一個(gè)DLL庫，為了能夠讓C語言也能夠調(diào)用你的DLL輸出(Export)的函數(shù)，你需要用extern "C"來強(qiáng)制編譯器不要修改你的

函數(shù)名。

通常，在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)文件中的符號(hà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符號(hào)來引用的，而在C編譯器生成的目標(biāo)文件中，foo()函數(shù)是由_foo指代的。但連接器工作的時(shí)候，它

可不管上層采用的是什么語言，它只認(rèn)目標(biāo)文件中的符號(hào)。于是，連接器將會(huì)發(fā)現(xiàn)在.cpp中調(diào)用了foo()函數(shù)，但是在其它的目標(biāo)文件中卻找不

到_fooii這個(gè)符號(hào)，于是提示連接過程出錯(cuò)。extern "C" {}這種語法形式就是用來解決這個(gè)問題的。本文將以示例對(duì)這個(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)非常簡(jiǎ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è)簡(jiǎn)單的類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提示找不到對(duì)函數(shù)ThisIsTest()的引用。

為了更清楚地說明問題的原因，我們采用下面的方式先把目標(biāo)文件編譯出來，然后看目標(biāo)文件中到底都有些什么符號(hà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符號(hào)，這個(gè)符號(hào)就是源文件中定義的

ThisIsTest()函數(shù)了。而在采用g++編譯了main.cpp之后，在其目標(biāo)文件main.o中有一個(gè)_Z10ThisIsTestii符號(hào)，這個(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)

文件中又有哪些符號(hà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è)符號(hào)ThisIsTest，這個(gè)符號(hào)引用的就是ThisIsTest()函數(shù)了。顯

然，此時(shí)在兩個(gè)目標(biāo)文件中都存在同樣的ThisIsTest符號(hào)，因此認(rèn)為它們引用的實(shí)際上同一個(gè)函數(shù)，于是就將兩個(gè)目標(biāo)文件連接在一起，凡是

出現(xiàn)程序代碼段中有ThisIsTest符號(hào)的地方都用ThisIsTest()函數(shù)的實(shí)際地址代替。另外，還可以看到，僅僅被extern "C" {}包圍起來的函數(shù)

采用這樣的目標(biāo)符號(hào)形式，對(duì)于main.cpp中的FOO類的成員函數(shù)，在兩種編譯方式后的符號(hào)名都是經(jīng)過“粉碎”了的。

因此，綜合上面的分析，我們可以得出如下結(jié)論：采用extern "C" {} 這種形式的聲明，可以使得CPP與C之間的接口具有互通性，不會(huì)由于語

言內(nèi)部的機(jī)制導(dǎo)致連接目標(biāo)文件的時(shí)候出現(xiàn)錯(cuò)誤。需要說明的是，上面只是根據(jù)我的試驗(yàn)結(jié)果而得出的結(jié)論。由于對(duì)于CPP用得不是很多，了解

得也很少，因此對(duì)其內(nèi)部處理機(jī)制并不是很清楚，如果需要深入了解這個(gè)問題的細(xì)節(jié)請(qǐng)參考相關(guān)資料。

?

第二種理解
時(shí)常在cpp的代碼之中看到這樣的代碼:

#ifdef __cplusplus

extern "C" {

#endif

?

//一段代碼

?

#ifdef __cplusplus

}

#endif
?

　　這樣的代碼到底是什么意思呢？首先，__cplusplus是cpp中的自定義宏，那么定義了這個(gè)宏的話表示這是一段cpp的代碼，也就是說，上面

的代碼的含義是:如果這是一段cpp的代碼，那么加入extern "C"{和}處理其中的代碼。

　　要明白為何使用extern "C"，還得從cpp中對(duì)函數(shù)的重載處理開始說起。在c++中，為了支持重載機(jī)制，在編譯生成的匯編碼中，要對(duì)函數(shù)

的名字進(jìn)行一些處理，加入比如函數(shù)的返回類型等等.而在C中，只是簡(jiǎn)單的函數(shù)名字而已，不會(huì)加入其他的信息.也就是說:C++和C對(duì)產(chǎn)生的函

數(shù)名字的處理是不一樣的.

　　比如下面的一段簡(jiǎn)單的函數(shù)，我們看看加入和不加入extern "C"產(chǎn)生的匯編代碼都有哪些變化:

int f(void)

{

return 1;

}
?

　　在加入extern "C"的時(shí)候產(chǎn)生的匯編代碼是:

.file "test.cxx"

.text

.align 2

.globl _f

.def _f; .scl 2; .type 32; .endef

_f:

pushl %ebp

movl %esp， %ebp

movl $1， %eax

popl %ebp

ret
?

　　但是不加入了extern "C"之后

.file "test.cxx"

.text

.align 2

.globl __Z1fv

.def __Z1fv; .scl 2; .type 32; .endef

__Z1fv:

pushl %ebp

movl %esp， %ebp

movl $1， %eax

popl %ebp

ret
?

　　兩段匯編代碼同樣都是使用gcc -S命令產(chǎn)生的，所有的地方都是一樣的，唯獨(dú)是產(chǎn)生的函數(shù)名，一個(gè)是_f，一個(gè)是__Z1fv。

　　明白了加入與不加入extern "C"之后對(duì)函數(shù)名稱產(chǎn)生的影響，我們繼續(xù)我們的討論:為什么需要使用extern "C"呢？C++之父在設(shè)計(jì)C++之時(shí)

，考慮到當(dāng)時(shí)已經(jīng)存在了大量的C代碼，為了支持原來的C代碼和已經(jīng)寫好C庫，需要在C++中盡可能的支持C，而extern "C"就是其中的一個(gè)策略

。

　　試想這樣的情況:一個(gè)庫文件已經(jīng)用C寫好了而且運(yùn)行得很良好，這個(gè)時(shí)候我們需要使用這個(gè)庫文件，但是我們需要使用C++來寫這個(gè)新的代

碼。如果這個(gè)代碼使用的是C++的方式鏈接這個(gè)C庫文件的話，那么就會(huì)出現(xiàn)鏈接錯(cuò)誤.我們來看一段代碼:首先，我們使用C的處理方式來寫一個(gè)

函數(shù)，也就是說假設(shè)這個(gè)函數(shù)當(dāng)時(shí)是用C寫成的:

//f1.c

extern "C"

{

void f1()

{

return;

}

}
?

　　編譯命令是:gcc -c f1.c -o f1.o 產(chǎn)生了一個(gè)叫f1.o的庫文件。再寫一段代碼調(diào)用這個(gè)f1函數(shù):

// test.cxx

//這個(gè)extern表示f1函數(shù)在別的地方定義，這樣可以通過

//編譯，但是鏈接的時(shí)候還是需要

//鏈接上原來的庫文件.

extern void f1();

?

int main()

{

f1();

?

return 0;

}
?

　　通過gcc -c test.cxx -o test.o 產(chǎn)生一個(gè)叫test.o的文件。然后，我們使用gcc test.o f1.o來鏈接兩個(gè)文件，可是出錯(cuò)了，錯(cuò)誤的提示

是:

test.o(.text + 0x1f):test.cxx: undefine reference to 'f1()'
?

　　也就是說，在編譯test.cxx的時(shí)候編譯器是使用C++的方式來處理f1()函數(shù)的，但是實(shí)際上鏈接的庫文件卻是用C的方式來處理函數(shù)的，所

以就會(huì)出現(xiàn)鏈接過不去的錯(cuò)誤:因?yàn)殒溄悠髡也坏胶瘮?shù)。

　　因此，為了在C++代碼中調(diào)用用C寫成的庫文件，就需要用extern "C"來告訴編譯器:這是一個(gè)用C寫成的庫文件，請(qǐng)用C的方式來鏈接它們。

　　比如，現(xiàn)在我們有了一個(gè)C庫文件，它的頭文件是f.h，產(chǎn)生的lib文件是f.lib，那么我們?nèi)绻贑++中使用這個(gè)庫文件，我們需要這樣寫

:

extern "C"

{

#include "f.h"

}
?

　　回到上面的問題，如果要改正鏈接錯(cuò)誤，我們需要這樣子改寫test.cxx:

extern "C"

{

extern void f1();

}

?

int main()

{

f1();

?

return 0;

}
?

重新編譯并且鏈接就可以過去了.

總結(jié)

C和C++對(duì)函數(shù)的處理方式是不同的.extern "C"是使C++能夠調(diào)用C寫作的庫文件的一個(gè)手段，如果要對(duì)編譯器提示使用C的方式來處理函數(shù)的話，那么就要使用extern "C"來說明。

總結(jié)

以上是生活随笔為你收集整理的C和C++混合编程(__cplusplus 与 external c 的使用)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。