第一種理解
比如說你用C++開發了一個DLL庫,為了能夠讓C語言也能夠調用你的DLL輸出(Export)的函數,你需要用extern "C"來強制編譯器不要修改你的
函數名。
通常,在C語言的標頭檔中經常可以看到類似下面這種形式的代碼:
#ifdef __cplusplus
extern "C" {
#endif
/**** some declaration or so *****/
#ifdef __cplusplus
}
#endif /* end of __cplusplus */
那麼,這種寫法什麼用呢。實際上,這是為了讓CPP能夠與C介面而採用的一種文法形式。之所以採用這種方式,是因為兩種語言之間的一些差
異所導致的。由於CPP支援多態性,也就是具有相同函數名的函數可以完成不同的功能,CPP通常是通過參數區分具體調用的是哪一個函數。在
編譯的時候,CPP編譯器會將參數類型和函數名串連在一起,於是在程式編譯成為目標檔案以後,CPP編譯器可以直接根據目標檔案中的符號名
將多個目標檔案串連成一個目標檔案或者可執行檔。但是在C語言中,由於完全沒有多態性的概念,C編譯器在編譯時間除了會在函數名前面添
加一個底線之外,什麼也不會做(至少很多編譯器都是這樣乾的)。由於這種的原因,當採用CPP與C混合編程的時候,就可能會出問題。假
設在某一個標頭檔中定義了這樣一個函數:
int foo(int a, int b);
而這個函數的實現位於一個.c檔案中,同時,在.cpp檔案中調用了這個函數。那麼,當CPP編譯器編譯這個函數的時候,就有可能會把這個函數
名改成_fooii,這裡的ii表示函數的第一參數和第二參數都是整型。而C編譯器卻有可能將這個函數名編譯成_foo。也就是說,在CPP編譯器得
到的目標檔案中,foo()函數是由_fooii符號來引用的,而在C編譯器產生的目標檔案中,foo()函數是由_foo指代的。但連接器工作的時候,它
可不管上層採用的是什麼語言,它只認目標檔案中的符號。於是,連接器將會發現在.cpp中調用了foo()函數,但是在其它的目標檔案中卻找不
到_fooii這個符號,於是提示串連過程出錯。extern "C" {}這種文法形式就是用來解決這個問題的。本文將以樣本對這個問題進行說明。
首先假設有下面這樣三個檔案:
/* 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
在這個標頭檔中只定義了一個函數,ThisIsTest()。這個函數被定義為一個外部函數,可以被包括到其它程式檔案中。假設ThisIsTest()函數
的實現位於test_extern_c.c檔案中:
/* test_extern_c.c */
#include "test_extern_c.h"
int ThisIsTest(int a, int b)
{
return (a + b);
}
可以看到,ThisIsTest()函數的實現非常簡單,就是將兩個參數的相加結果返回而已。現在,假設要從CPP中調用ThisIsTest()函數:
/* 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);
}
在這個CPP源檔案中,定義了一個簡單的類FOO,在其成員函數bar()中調用了ThisIsTest()函數。下面看一下如果採用gcc編譯test_extern_c.c
,而採用g++編譯main.cpp並與test_extern_c.o串連會發生什麼情況:
[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
可以看到,程式沒有任何異常,完全按照預期的方式工作。那麼,如果將test_extern_c.h中的extern "C" {}所在的那幾行注釋掉會怎樣呢。
注釋後的test_extern_c.h檔案內容如下:
/* 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的時候就會出錯,連接器ld提示找不到對函數ThisIsTest()的引用。
為了更清楚地說明問題的原因,我們採用下面的方式先把目標檔案編譯出來,然後看目標檔案中到底都有些什麼符號:
[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之後,在其目標檔案test_extern_c.o中的有一個ThisIsTest符號,這個符號就是源檔案中定義的
ThisIsTest()函數了。而在採用g++編譯了main.cpp之後,在其目標檔案main.o中有一個_Z10ThisIsTestii符號,這個就是經過g++編譯器“粉
碎”過後的函數名。其最後的兩個字元i就表示第一參數和第二參數都是整型。而為什麼要加一個首碼_Z10我並不清楚,但這裡並不影響我們的
討論,因此不去管它。顯然,這就是原因的所在,其原理在本文開頭已作了說明。
那麼,為什麼採用了extern "C" {}形式就不會有這個問題呢,我們就來看一下當test_extern_c.h採用extern "C" {}的形式時編譯出來的目標
檔案中又有哪些符號:
[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
注意到這裡和前面有什麼不同沒有,可以看到,在兩個目標檔案中,都有一個符號ThisIsTest,這個符號引用的就是ThisIsTest()函數了。顯
然,此時在兩個目標檔案中都存在同樣的ThisIsTest符號,因此認為它們引用的實際上同一個函數,於是就將兩個目標檔案串連在一起,凡是
出現程式碼段中有ThisIsTest符號的地方都用ThisIsTest()函數的實際地址代替。另外,還可以看到,僅僅被extern "C" {}包圍起來的函數
採用這樣的目標符號形式,對於main.cpp中的FOO類的成員函數,在兩種編譯方式後的符號名都是經過“粉碎”了的。
因此,綜合上面的分析,我們可以得出如下結論:採用extern "C" {} 這種形式的聲明,可以使得CPP與C之間的介面具有互連性,不會由於語
言內部的機制導致串連目標檔案的時候出現錯誤。需要說明的是,上面只是根據我的實驗結果而得出的結論。由於對於CPP用得不是很多,瞭解
得也很少,因此對其內部處理機制並不是很清楚,如果需要深入瞭解這個問題的細節請參考相關資料。
第二種理解
時常在cpp的代碼之中看到這樣的代碼:
#ifdef __cplusplus
extern "C" {
#endif
//一段代碼
#ifdef __cplusplus
}
#endif
這樣的代碼到底是什麼意思呢。首先,__cplusplus是cpp中的自訂宏,那麼定義了這個宏的話表示這是一段cpp的代碼,也就是說,上面
的代碼的含義是:如果這是一段cpp的代碼,那麼加入extern "C"{和}處理其中的代碼。
要明白為何使用extern "C",還得從cpp中對函數的重載處理開始說起。在c++中,為了支援重載機制,在編譯產生的彙編碼中,要對函數
的名字進行一些處理,加入比如函數的傳回型別等等.而在C中,只是簡單的函數名字而已,不會加入其他的資訊.也就是說:C++和C對產生的函
數名字的處理是不一樣的.
比如下面的一段簡單的函數,我們看看加入和不加入extern "C"產生的彙編代碼都有哪些變化:
int f(void)
{
return 1;
}
在加入extern "C"的時候產生的彙編代碼是:
.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命令產生的,所有的地方都是一樣的,唯獨是產生的函數名,一個是_f,一個是__Z1fv。
明白了加入與不加入extern "C"之後對函數名稱產生的影響,我們繼續我們的討論:為什麼需要使用extern "C"呢。C++之父在設計C++之時
,考慮到當時已經存在了大量的C代碼,為了支援原來的C代碼和已經寫好C庫,需要在C++中儘可能的支援C,而extern "C"就是其中的一個策略
。
試想這樣的情況:一個庫檔案已經用C寫好了而且運行得很良好,這個時候我們需要使用這個庫檔案,但是我們需要使用C++來寫這個新的代
碼。如果這個代碼使用的是C++的方式連結這個C庫檔案的話,那麼就會出現連結錯誤.我們來看一段代碼:首先,我們使用C的處理方式來寫一個
函數,也就是說假設這個函數當時是用C寫成的:
//f1.c
extern "C"
{
void f1()
{
return;
}
}
編譯命令是:gcc -c f1.c -o f1.o 產生了一個叫f1.o的庫檔案。再寫一段代碼調用這個f1函數:
// test.cxx
//這個extern表示f1函數在別的地方定義,這樣可以通過
//編譯,但是連結的時候還是需要
//連結上原來的庫檔案.
extern void f1();
int main()
{
f1();
return 0;
}
通過gcc -c test.cxx -o test.o 產生一個叫test.o的檔案。然後,我們使用gcc test.o f1.o來連結兩個檔案,可是出錯了,錯誤的提示
是:
test.o(.text + 0x1f):test.cxx: undefine reference to 'f1()'
也就是說,在編譯test.cxx的時候編譯器是使用C++的方式來處理f1()函數的,但是實際上連結的庫檔案卻是用C的方式來處理函數的,所
以就會出現連結過不去的錯誤:因為連結器找不到函數。
因此,為了在C++代碼中調用用C寫成的庫檔案,就需要用extern "C"來告訴編譯器:這是一個用C寫成的庫檔案,請用C的方式來連結它們。
比如,現在我們有了一個C庫檔案,它的標頭檔是f.h,產生的lib檔案是f.lib,那麼我們如果要在C++中使用這個庫檔案,我們需要這樣寫
:
extern "C"
{
#include "f.h"
}
回到上面的問題,如果要改正連結錯誤,我們需要這樣子改寫test.cxx:
extern "C"
{
extern void f1();
}
int main()
{
f1();
return 0;
}
重新編譯並且連結就可以過去了.
總結
C和C++對函數的處理方式是不同的.extern "C"是使C++能夠調用C寫作的庫檔案的一個手段,如果要對編譯器提示使用C的方式來處理函數的話,那麼就要使用extern "C"來說明。