1、第一種了解
比如說你用C++開發了一個DLL庫，為了能夠讓C語言也能夠調用你的DLL輸出(Export)的函數，你需要用extern "C"來強制編譯器不要修改你的函數名。
通常，在C語言的頭檔案中經常可以看到類似下面這種形式的代碼：
#ifdef __cplusplus
extern "C" {
#endif
#ifdef __cplusplus
}
#endif
那麼，這種寫法什麼用呢？實際上，這是為了讓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" {}這種文法形式就是用來解決這個問題的。本文将以示例對這個問題進行說明。
首先假設有下面這樣三個檔案：
#ifndef __TEST_EXTERN_C_H__
#define __TEST_EXTERN_C_H__
#ifdef __cplusplus
extern "C" {
#endif
extern int ThisIsTest(int a, int b);
#ifdef __cplusplus
}
#endif
#endif
在這個頭檔案中隻定義了一個函數，ThisIsTest()。這個函數被定義為一個外部函數，可以被包括到其它程式檔案中。假設ThisIsTest()函數的實作位于test_extern_c.c檔案中：
＃i nclude "test_extern_c.h"
int ThisIsTest(int a, int b)
{
return (a + b);
}
可以看到，ThisIsTest()函數的實作非常簡單，就是将兩個參數的相加結果傳回而已。現在，假設要從CPP中調用ThisIsTest()函數：
＃i nclude "test_extern_c.h"
＃i nclude <stdio.h>
＃i nclude <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連接配接會發生什麼情況：
[[email protected] src]$ gcc -c test_extern_c.c
[[email protected] src]$ g++ main.cpp test_extern_c.o
[[email protected] src]$ ./a.out 4 5
result=9
可以看到，程式沒有任何異常，完全按照預期的方式工作。那麼，如果将test_extern_c.h中的extern "C" {}所在的那幾行注釋掉會怎樣呢？注釋後的test_extern_c.h檔案内容如下：
#ifndef __TEST_EXTERN_C_H__
#define __TEST_EXTERN_C_H__
//#ifdef __cplusplus
//extern "C" {
//#endif
extern int ThisIsTest(int a, int b);
//#ifdef __cplusplus
// }
//#endif
#endif
之外，其它檔案不做任何的改變，仍然采用同樣的方式編譯test_extern_c.c和main.cpp檔案：
[[email protected] src]$ gcc -c test_extern_c.c
[[email protected] 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()的引用。
為了更清楚地說明問題的原因，我們采用下面的方式先把目标檔案編譯出來，然後看目标檔案中到底都有些什麼符号：
[[email protected] src]$ gcc -c test_extern_c.c
[[email protected] 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
[[email protected] src]$ g++ -c main.cpp
[[email protected] 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" {}的形式時編譯出來的目标檔案中又有哪些符号：
[[email protected] src]$ gcc -c test_extern_c.c
[[email protected] 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
[[email protected] src]$ g++ -c main.cpp
[[email protected] 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用得不是很多，了解得也很少，是以對其内部處理機制并不是很清楚，如果需要深入了解這個問題的細節請參考相關資料。
2、第二種了解
時常在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"來說明。
![python算法之二分查找[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)