用#include可以包含其他頭文件中變量、函數的聲明，為什么還要extern關鍵字？
如果我想引用一個全局變量或函數a，我只要直接在源文件中包含#include<xxx.h> (xxx.h包含了a的聲明)不就可以了么，為什么還要用extern呢？？
這個問題一直也是似是而非的困擾着我許久，經過實踐和查找資料，有如下總結：
一、頭文件
首先說下頭文件，其實頭文件對計算機而言沒什么作用，她只是在預編譯時在#include的地方展開一下，沒別的意義了，其實頭文件主要是給別人看的。
我做過一個實驗，將頭文件的后綴改成xxx.txt，然后在引用該頭文件的地方用
#include"xxx.txt"
編譯，鏈接都很順利的過去了，由此可知，頭文件僅僅為閱讀代碼作用，沒其他的作用了！
不管是C還是C++，你把你的函數，變量或者結構體，類啥的放在你的.c或者.cpp文件里。然后編譯成lib,dll,obj,.o等等，然后別人用的 時候，最基本的gcc hisfile.cpp yourfile.o|obj|dll|lib 等等。
但對於我們程序員而言，他們怎么知道你的lib,dll...里面到底有什么東西？要看你的頭文件。你的頭文件就是對用戶的說明。函數，參數，各種各樣的接口的說明。
那既然是說明，那么頭文件里面放的自然就是關於函數，變量，類的“聲明”(對函數來說，也叫函數原型)了。記着，是“聲明”，不是“定義”。
聲明和定義的區別。
變量的聲明有兩種情況： 1、一種是需要建立存儲空間的。例如：int a 在聲明的時候就已經建立了存儲空間。 2、另一種是不需要建立存儲空間的。 例如：extern int a 其中變量a是在別的文件中定義的。 聲明是向編譯器介紹名字－－標識符。它告訴編譯器“這個函數或變量在某處可找到，它的模樣象什么”。 而定義是說：“在這里建立變量”或“在這里建立函數”。它為名字分配存儲空間。無論定義的是函數還是變量，編譯器都要為它們在定義點分配存儲空間。 對於變量，編譯器確定變量的大小，然后在內存中開辟空間來保存其數據，對於函數，編譯器會生成代碼，這些代碼最終也要占用一定的內存。 總之就是：把建立空間的聲明成為“定義”，把不需要建立存儲空間的成為“聲明”。 基本類型變量的聲明和定義（初始化）是同時產生的；而對於對象來說，聲明和定義是分開的。 例如：類A 如果A a;就是一個聲明，告訴編譯器a是A類的一個對象變量，但是不進行初始化； 如果以后a=new A();這就是初始化，分配了空間。 （我們聲明的最終目的是為了提前使用，即在定義之前使用，如果不需要提前使用就沒有單獨聲明的必要，變量是如此，函數也是如此，所以聲明不會分配存儲空間，只有定義時才會分配存儲空間。） 用static來聲明一個變量的作用有二： (1)對於局部變量用static聲明，則是為該變量分配的空間在整個程序的執行期內都始終存在。 (2)外部變量用static來聲明，則該變量的作用只限於本文件模塊。 補充： 什么是定義？什么是聲明？它們之間的區別是什么？ 所謂定義就是（編譯器）創建一個對象，為這個對象分配一塊內存，並給它取上一個名字，這個名字就是就是我們經常所說的變量名或對象名。 聲明有2重含義： （1） 告訴編譯器，這個名字已經匹配到一塊內存上，下面的代碼用到變量或者對象是在別的地方定義的。聲明可以出現多次。 （2） 告訴編譯器，這個名字已經被預定了，別的地方再也不能用它來作為變量名或對象名。 定義和聲明的最重要區別就是： 定義創建對象並為這個對象分配了內存，聲明沒有分配內存。
所以，最好不要傻嘻嘻的在頭文件里定義什么東西。比如全局變量：
/*xx頭文件*/
#ifndef _XX_頭文件.H
#define _XX_頭文件.H
int A;
#endif
那么，很糟糕的是，這里的int A是個全局變量的定義，所以如果這個頭文件被多次引用的話，你的A會被重復定義，顯然語法上錯了。只不過有了這個#ifndef的條件編譯，所以能保證你的頭文件只被引用一次，不過也許還是不會出岔子，但若多個c文件包含這個頭文件時還是會出錯的，因為宏名有效范圍僅限於本c源文件(指宏所在的文件和include該文件的文件)，所以在這多個c文件編譯時是不會出錯的，但在鏈接時就會報錯，說你多處定義了同一個變量，
Linking...
incl2.obj : error LNK2005: "int glb" (?glb@@3HA) already defined in incl1.obj
Debug/incl.exe : fatal error LNK1169: one or more multiply defined symbols found
注意！！！
二、extern
這個關鍵字真的比較可惡，在定義變量的時候，這個extern居然可以被省略(定義時，默認均省略)；在聲明變量的時候，這個extern必須添加在變量前，所以有時會讓你搞不清楚到底是聲明還是定義。或者說，變量前有extern不一定就是聲明，而變量前無extern就只能是定義。注：定義要為變量分配內存空間；而聲明不需要為變量分配內存空間。
下面分變量和函數兩類來說：
（1）變量
尤其是對於變量來說。
extern int a;//聲明一個全局變量a
int a; //定義一個全局變量a
extern int a =0 ;//定義一個全局變量a 並給初值。
int a =0;//定義一個全局變量a,並給初值，
第四個 等於 第 三個，都是定義一個可以被外部使用的全局變量，並給初值。
糊塗了吧，他們看上去可真像。但是定義只能出現在一處。也就是說，不管是int a；還是extern int a=0；還是int a=0;都只能出現一次，而那個extern int a可以出現很多次。
當你要引用一個全局變量的時候，你就必須要聲明，extern int a; 這時候extern不能省略，因為省略了，就變成int a;這是一個定義，不是聲明。注：extern int a; 中類型int可省略，即extern a; 但其他類型則不能省略。
（2）函數
函數，對於函數也一樣，也是定義和聲明，定義的時候用extern，說明這個函數是可以被外部引用的，聲明的時候用extern說明這是一個聲明。 但由於函數的定義和聲明是有區別的，定義函數要有函數體，聲明函數沒有函數體(還有以分號結尾)，所以函數定義和聲明時都可以將extern省略掉，反正其他文件也是知道這個函數是在其他地方定義的，所以不加extern也行。兩者如此不同，所以省略了extern也不會有問題。
比如：
/*某cpp文件*/
int fun(void)
{
return 0;
}
很好，我們定義了一個全局函數
/*另一cpp文件*/
int fun(void);
我們對它做了個聲明，然后后面就可以用了
加不加extern都一樣
我們也可以把對fun的聲明 放在一個頭文件里，最后變成這樣
/*fun.h*/
int fun(void); //函數聲明，所以省略了extern，完整些是extern int fun(void);
/*對應的fun.cpp文件*/
int fun(void)
{
return 0;
}//一個完整的全局函數定義，因為有函數體，extern同樣被省略了。
然后，一個客戶，一個要使用你的fun的客戶，把這個頭文件包含進去，ok，一個全局的聲明。沒有問題。
但是，對應的，如果是這個客戶要使用全局變量，那么要extern 某某變量；不然就成了定義了。
總結：
對變量而 言，如果你想在本源文件(例如文件名A)中使用另一個源文件(例如文件名B)的變量，方法有2種：(1)在A文件中必須用extern聲明在B文件中定義 的變量(當然是全局變量)；(2)在A文件中添加B文件對應的頭文件，當然這個頭文件包含B文件中的變量聲明，也即在這個頭文件中必須用extern聲明 該變量，否則，該變量又被定義一次。
對函數而 言，如果你想在本源文件(例如文件名A)中使用另一個源文件(例如文件名B)的函數，方法有2種：(1)在A文件中用extern聲明在B文件中定義的函 數(其實，也可省略extern，只需在A文件中出現B文件定義函數原型即可)；(2)在A文件中添加B文件對應的頭文件，當然這個頭文件包含B文件中的 函數原型，在頭文件中函數可以不用加extern。
******************************************************************************************************************************************************
對上述總結換一種說法：
(a)對於一個文件中調用另一個文件的全局變量，因為全局變量一般定義在原文件.c中，我們不能用#include包含源文件而只能包含頭文件，所以常用的方法是用extern int a來聲明外部變量。 另外一種方法是可以是在a.c文件中定義了全局變量int global_num ，可以在對應的a.h頭文件中寫extern int global_num ，這樣其他源文件可以通過include a.h來聲明她是外部變量就可以了。
（b）還有變量和函數的不同舉例
int fun(); 和 extern int fun(); 都是聲明(定義要有實現體)。 用extern int fun()只是更明確指明是聲明而已。
而 int a; 是定義
extern int a; 是聲明。
(3)此外，extern修飾符可用於C＋＋程序中調用c函數的規范問題。
比如在C＋＋中調用C庫函數，就需要在C＋＋程序中用extern “C”聲明要引用的函數。這是給鏈接器用的，告訴鏈接器在鏈接的時候用C函數規范來鏈接。主要原因是C＋＋和C程序編譯完成后在目標代碼中命名規則不同。
C＋＋語言在編譯的時候為了解決的多態問題，會將名和參數聯合起來生成一個中間的名稱，而c語言則不會，因此會造成鏈接時找不到對應的情況，此時C就需要用extern “C”進行鏈接指定，這告訴編譯器，請保持我的名稱，不要給我生成用於鏈接的中間名。
注意： 如果一個函數在同一文件中不只被聲明一次則鏈接指示符可以出現在每個聲明中，也可以只出現在函數的第一次聲明中，在這種情況下第二個及以后的聲明都接受第一個聲明中鏈接指示符指定的鏈接規則例如
// ---- myMath.h ----
extern "C" double calc( double );
// ---- myMath.C ----
// 在Math.h 中的calc() 的聲明
#include "myMath.h"
// 定義了extern "C" calc() 函數
// calc() 可以從C 程序中被調用
double calc( double dparm ) { // ...
三、extern和頭文件的聯系
這種聯系也解決了最初提出的2個問題：
(a)用#include可以包含其他頭文件中變量、函數的聲明，為什么還要extern關鍵字？
(b)如果我想引用一個全局變量或函數a，我只要直接在源文件中包含#include<xxx.h> (xxx.h包含了a的聲明)不就可以了么，為什么還要用extern呢？？
答 案：如果一個文件(假設文件名A)要大量引用另一個文件(假設文件名B)中定義的變量或函數，則使用頭文件效率更高，程序結構也更規范。其他文件(例如文 件名C、D等)要引用文件名B中定義的變量或函數，則只需用#include包含文件B對應的頭文件(當然，這個頭文件只有對變量或函數的聲明，絕不能有 定義)即可。
********************************************************************************************************************************************
那是一個被遺忘的年代，那時，編譯器只認識.c(或.cpp)文件，而不知道.h是何物的年代。
那時的人們寫了很多的.c(或.cpp)文件，漸漸地，人們發現在很多.c(或.cpp)文件中的聲明變量或函數原型是相同的，但他們卻不得不一個字一個 字地重復地將這些內容敲入每個.c(或.cpp)文件。但更為恐怖的是，當其中一個聲明有變更時，就需要檢查所有的.c(或.cpp)文件，並修改其中的 聲明，啊~，簡直是世界末日降臨!
終於，有人（或許是一些人）再不能忍受這樣的折磨，他（們）將重復的部分提取出來，放在一個新文件里，然后在需要的.c(或.cpp)文件中敲 入#include XXXX這樣的語句。這樣即使某個聲明發生了變更，也再不需要到處尋找與修改了---世界還是那么美好！
因為這個新文件，經常被放在.c(或.cpp)文件的頭部，所以就給它起名叫做“頭文件”，擴展名是.h.
從此，編譯器（其實是其中預處理器）就知道世上除了.c(或.cpp)文件，還有個.h的文件，以及一個叫做#include命令。
四、頭文件內容
如果想在一個C文件里面引用另外一個C文件里面的變量，怎！么！辦？
我們的做法是將變量在H文件中聲明為ertern，然后在其他文件中導入這個H文件。
這里需要注意的是，如果導入了H文件，那就不能聲明同名的變量了。
另外，H文件中的聲明變量必須是在別的文件里面已經聲明過的。這里特別強調變！量！
如上圖。
左邊是H文件，里面聲明的一個ppp變量。在右邊的文件里面引入H文件。但是！這個ppp變量是不能直接用的。
warning: data definition has no type or storage class [enabled by default]
ppp = 1;
^
這個ppp實際上還是未定義的變量。所以H文件出現不帶extern的變量聲明是沒有意義的。
但是宏定義和typedef都是可以在H文件里面的。如果在H文件里面已經typedef的，在導入H的C文件里面就可以直接用了，而且在次typedef就是重復。
所以這里總結一下H文件里面有什么。
1 #define
2 typedef
3 extern 變量
4 函數聲明
轉自：http://www.cnblogs.com/tshua/p/5741009.html
http://lpy999.blog.163.com/blog/static/117372061201182051413310/
http://blog.csdn.net/feitianxuxue/article/details/7204116
http://blog.csdn.net/qc_liu/article/details/42236631