extern 和 external“C”的分析

extern 和 extern "C" 分析

extern

extern是C/C++語言中表明函數和全局變量作用範圍（可見性）的關鍵字：它告訴編譯器，其聲明的函數和變量可以在本子產品或其它子產品中使用。

1。對于extern變量來說，僅僅是一個變量的聲明，其并不是在定義配置設定記憶體空間。如果該變量定義多次，會有連接配接錯誤

2。通常，在子產品的頭檔案中對本子產品提供給其它子產品引用的函數和全局變量以關鍵字 extern聲明。也就是說c檔案裡面定義，如果該函數或者變量與開放給外面，則在h檔案中用extern加以聲明。是以外部檔案隻用include該h 檔案就可以了。而且編譯階段，外面是找不到該函數的，但是不報錯。link階段會從定義子產品生成的目标代碼中找到此函數。

3。與extern對應的關鍵字是static，被它修飾的全局變量和函數隻能在本子產品中使用。

1 問題：常常見extern放在函數的前面成為函數聲明的一部分，那麼，C語言的關鍵字extern在函數的聲明中起什麼作用？ 答案與分析：如果函數的聲明中帶有關鍵字extern，僅僅是暗示這個函數可能在别的源檔案裡定義，沒有其它作用。即下述兩個函數聲明沒有明顯的差別：extern int fun() 和 int fun()；當然，這樣的用處還是有的，就是在程式中取代include “*.h”來聲明函數，在一些複雜的項目中，我比較習慣在所有的函數聲明前添加extern修飾。

2 問題：extern 變量　　在一個源檔案裡定義了一個數組： char a[6]; 在另外一個檔案裡用下列語句進行了聲明： extern char *a；　　請問，這樣可以嗎？　　答案與分析：　　1)、不可以，程式運作時會告訴你非法通路。原因在于，指向類型T的指針并不等價于類型T的數組。extern char *a聲明的是一個指針變量而不是字元數組，是以與實際的定義不同，進而造成運作時非法通路。應該将聲明改為extern char a[ ]。　　2)、例子分析如下，如果a[] = "abcd",則外部變量a=0x61626364 (abcd的ASCII碼值)，*a顯然沒有意義，如下圖：　　顯然a指向的空間（0x61626364）沒有意義，易出現非法記憶體通路。　　3)、這提示我們，在使用extern時候要嚴格對應聲明時的格式，在實際程式設計中，這樣的錯誤屢見不鮮。　　4)、extern用在變量聲明中常常有這樣一個作用，你在*.c檔案中聲明了一個全局的變量，這個全局的變量如果要被引用，就放在*.h中并用extern來聲明。　

3 問題：extern 函數1 　　常常見extern放在函數的前面成為函數聲明的一部分，那麼，C語言的關鍵字extern在函數的聲明中起什麼作用？　　答案與分析：　　如果函數的聲明中帶有關鍵字extern，僅僅是暗示這個函數可能在别的源檔案裡定義，沒有其它作用。即下述兩個函數聲明沒有明顯的差別： extern int f(); 和int f(); 　　當然，這樣的用處還是有的，就是在程式中取代include “*.h”來聲明函數，在一些複雜的項目中，我比較習慣在所有的函數聲明前添加extern修飾。 　

4 問題：extern 函數2 　　當函數提供方單方面修改函數原型時，如果使用方不知情繼續沿用原來的extern申明，這樣編譯時編譯器不會報錯。但是在運作過程中，因為少了或者多了輸入參數，往往會照成系統錯誤，這種情況應該如何解決？　　答案與分析：　　目前業界針對這種情況的處理沒有一個很完美的方案，通常的做法是提供方在自己的xxx_pub.h中提供對外部接口的聲明，然後調用方include該頭檔案，進而省去extern這一步。以避免這種錯誤。　　

寶劍有雙鋒，對extern的應用，不同的場合應該選擇不同的做法。 extern "C" 某企業曾經給出如下的一道面試題：面試題為什麼标準頭檔案都有類似以下的結構？

#ifndef __INCvxWorksh #define __INCvxWorksh

#ifdef __cplusplus extern "C" { #endif

#ifdef __cplusplus } #endif

#endif

分析 顯然，頭檔案中的編譯宏“#ifndef __INCvxWorksh、#define __INCvxWorksh、#endif” 的作用是防止該頭檔案被重複引用。 那麼 #ifdef __cplusplus extern "C" { #endif #ifdef __cplusplus } #endif 的作用又是什麼呢？

extern "C" 包含雙重含義，從字面上即可得到：首先，被它修飾的目标是“extern”的；其次，被它修飾的目标是“C”的。

讓我們來詳細解讀這兩重含義。

（1）extern "C"限定的函數或變量是extern類型的； extern是C/C++語言中表明函數和全局變量作用範圍（可見性）的關鍵字，該關鍵字告訴編譯器，其聲明的函數和變量可以在本子產品或其它子產品中使用。記住，下列語句： extern int a; 僅僅是一個變量的聲明，其并不是在定義變量a，并未為a配置設定記憶體空間。變量a在所有子產品中作為一種全局變量隻能被定義一次，否則會出現連接配接錯誤。通常，在子產品的頭檔案中對本子產品提供給其它子產品引用的函數和全局變量以關鍵字extern聲明。例如，如果子產品B欲引用該子產品A中定義的全局變量和函數時隻需包含子產品A的頭檔案即可。這樣，子產品B中調用子產品A中的函數時，在編譯階段，子產品B雖然找不到該函數，但是并不會報錯；它會在連接配接階段中從子產品 A編譯生成的目标代碼中找到此函數。

與extern對應的關鍵字是static，被它修飾的全局變量和函數隻能在本子產品中使用。是以，一個函數或變量隻可能被本子產品使用時，其不可能被extern “C”修飾。

（2）被extern "C"修飾的變量和函數是按照C語言方式編譯和連接配接的； 未加extern “C”聲明時的編譯方式首先看看C++中對類似C的函數是怎樣編譯的。作為一種面向對象的語言，C++支援函數重載，而過程式語言C則不支援。函數被C++編譯後在符号庫中的名字與C語言的不同。例如，假設某個函數的原型為： void foo( int x, int y ); 該函數被C編譯器編譯後在符号庫中的名字為_foo，而C++編譯器則會産生像_foo_int_int之類的名字（不同的編譯器可能生成的名字不同，但是都采用了相同的機制，生成的新名字稱為“mangled name”）。_foo_int_int這樣的名字包含了函數名、函數參數數量及類型資訊，C++就是靠這種機制來實作函數重載的。例如，在C++中，函數void foo( int x, int y )與void foo( int x, float y )編譯生成的符号是不相同的，後者為_foo_int_float。同樣地，C++中的變量除支援局部變量外，還支援類成員變量和全局變量。使用者所編寫程式的類成員變量可能與全局變量同名，我們以"."來區分。而本質上，編譯器在進行編譯時，與函數的處理相似，也為類中的變量取了一個獨一無二的名字，這個名字與使用者程式中同名的全局變量名字不同。

未加extern "C"聲明時的連接配接方式 假設在C++中，子產品A的頭檔案如下：

// 子產品A頭檔案　moduleA.h

#ifndef MODULE_A_H #define MODULE_A_H

int foo( int x, int y );

#endif

在子產品B中引用該函數：

// 子產品B實作檔案　moduleB.cpp

＃include "moduleA.h"

foo(2,3);

實際上，在連接配接階段，連接配接器會從子產品A生成的目标檔案moduleA.obj中尋找_foo_int_int這樣的符号

！ 加extern "C"聲明後的編譯和連接配接方式 加extern "C"聲明後，

子產品A的頭檔案變為： // 子產品A頭檔案　moduleA.h #ifndef MODULE_A_H #define MODULE_A_H extern "C" int foo( int x, int y );

#endif

在子產品B的實作檔案中仍然調用foo( 2,3 )，

其結果是：

（1）子產品A編譯生成foo的目标代碼時，沒有對其名字進行特殊處理，采用了C語言的方式；

（2）連接配接器在為子產品B的目标代碼尋找foo(2,3)調用時，尋找的是未經修改的符号名_foo。如果在子產品A中函數聲明了foo為extern "C"類型，而子產品B中包含的是extern int foo( int x, int y ) ，則子產品B找不到子產品A中的函數；反之亦然。

是以，可以用一句話概括extern “C”這個聲明的真實目的（任何語言中的任何文法特性的誕生都不是随意而為的，來源于真實世界的需求驅動。我們在思考問題時，不能隻停留在這個語言是怎麼做的，還要問一問它為什麼要這麼做，動機是什麼，這樣我們可以更深入地了解許多問題）：實作C++與C及其它語言的混合程式設計。明白了C++中extern "C"的設立動機，我們下面來具體分析extern "C"通常的使用技巧。

4.extern "C"的慣用法

（1）在C++中引用C語言中的函數和變量，在包含C語言頭檔案（假設為cExample.h）時，需進行下列處理： extern "C"

{ ＃include "cExample.h" }

而在C語言的頭檔案中，對其外部函數隻能指定為extern類型，C語言中不支援extern "C"聲明，在.c檔案中包含了extern "C"時會出現編譯文法錯誤。筆者編寫的C++引用C函數例子工程中包含的三個檔案的源代碼如下：

//c語言頭檔案：cExample.h

#ifndef C_EXAMPLE_H

#define C_EXAMPLE_H

extern int add(int x,int y);

#endif

// c語言實作檔案：cExample.c

＃include "cExample.h"

int add( int x, int y )

{ return x + y; }

// c++實作檔案，調用add：cppFile.cpp

extern "C"

{ ＃i nclude "cExample.h" }

int main(int argc, char* argv[])

{ add(2,3); return 0; }

如果C++調用一個C語言編寫的.DLL時，當包括.DLL的頭檔案或聲明接口函數時，應加extern "C" {　}。（2）在C中引用C++語言中的函數和變量時，C++的頭檔案需添加extern "C"，但是在C語言中不能直接引用聲明了extern "C"的該頭檔案，應該僅将C檔案中将C++中定義的extern "C"函數聲明為extern類型。筆者編寫的C引用C++函數例子工程中包含的三個檔案的源代碼如下：

//C++頭檔案 cppExample.h

#ifndef CPP_EXAMPLE_H #define CPP_EXAMPLE_H

extern "C" int add( int x, int y );

#endif

//C++實作檔案 cppExample.cpp

＃include "cppExample.h"

int add( int x, int y )

{ return x + y; }

// C實作檔案 cFile.c

// 這樣會編譯出錯：＃i nclude "cExample.h"

extern int add( int x, int y );

int main( int argc, char* argv[] )

{ add( 2, 3 ); return 0; }

簡短一點就是: 函數經過編譯系統的翻譯成彙編，函數名對應着彙編标号。因為C編譯函數名與得到的彙編代号基本一樣，如：fun()=>_fun, main=>_main 但是C++中函數名與得到的彙編代号有比較大的差别。如：由于函數重載，函數名一樣，但彙編代号絕對不能一樣。為了區分，編譯器會把函數名和參數類型合在一起作為彙編代号，這樣就解決了重載問題。具體如何把函數名和參數類型合在一起，要看編譯器的幫助說明了。這樣一來，如果C++調用C，如fun(),則調用名就不是C的翻譯結果_fun, 而是帶有參數資訊的一個名字，是以就不能調用到fun（），為了解決 這個問題，加上extern "C"表示該函數的調用規則是C的規則，則調用時就不使用C++規則的帶有參數資訊的名字，而是_fun,進而達到調用C函數的目的。

具體介紹

時常在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"來說明。