簡單的說其實要理解C文件與頭文件（即.h）有什麼不同之處，首先需要弄明白編譯器的工作過程，一般說來編譯器會做以下幾個過程：

1.預處理階段

2.詞法與語法分析階段

3.編譯階段，首先編譯成純彙編語句，再将之彙編成跟CPU相關的二進制碼，生成各個目标文件 (.obj文件)

4.連接階段，将各個目标文件中的各段代碼進行絕對地址定位，生成跟特定平台相關的可執行文件，當然，最後還可以用objcopy生成純二進制碼，也就是去掉了文件格式信息。（生成.exe文件）

編譯器在編譯時是以C文件為單位進行的，也就是說如果你的項目中一個C文件都沒有，那麼你的項目将無法編譯，連接器是以目标文件為單位，它将一個或多個目标文件進行函數與變量的重定位，生成最終的可執行文件，在PC上的程序開發，一般都有一個main函數，這是各個編譯器的約定，當然，你如果自己寫連接器腳本的話，可以不用main函數作為程序入口！！！！

（main .c文件 目标文件 可執行文件）

有了這些基礎知識，再言歸正傳，為了生成一個最終的可執行文件，就需要一些目标文件，也就是需要C文件，而這些C文件中又需要一個main函數作為可執行程序的入口，那麼我們就從一個C文件入手，假定這個C文件内容如下：

#include <stdio.h>

#include "mytest.h"

int main(int argc,char **argv)

{

test = 25;

printf("test.................%d\n",test);

}

mytest.h頭文件内容如下：

int test;

現在以這個例子來講解編譯器的工作：

1.預處理階段，編譯器以C文件作為一個單元，首先讀這個C文件，發現第一句與第二句是包含一個頭文件，就會在所有搜索路徑中尋找這兩個文件，找到之後，就會将相應頭文件中再去處理宏，變量，函數聲明，嵌套的頭文件包含等，檢測依賴關系，進行宏替換，看是否有重複定義與聲明的情況發生，最後将那些文件中所有的東東全部掃描進這個當前的C文件中，形成一個中間"C文件"

2.編譯階段，在上一步中相當于将那個頭文件中的test變量掃描進了一個中間C文件，那麼test變量就變成了這個文件中的一個全局變量，此時就将所有這個中間C文件的所有變量，函數分配空間，将各個函數編譯成二進制碼，按照特定目标文件格式生成目标文件，在這種格式的目标文件中進行各個全局變量，函數的符号描述，将這些二進制碼按照一定的标準組織成一個目标文件

3.連接階段，将上一步成生的各個目标文件，根據一些參數，連接生成最終的可執行文件，主要的工作就是重定位各個目标文件的函數，變量等，相當于将個目标文件中的二進制碼按一定的規範合到一個文件中再回到C文件與頭文件各寫什麼内容的話題上：理論上來說C文件與頭文件裡的内容，隻要是C語言所支持的，無論寫什麼都可以的，比如你在頭文件中寫函數體，隻要在任何一個C文件包含此頭文件就可以将這個函數編譯成目标文件的一部分（編譯是以C文件為單位的，如果不在任何C文件中包含此頭文件的話，這段代碼就形同虛設），你可以在C文件中進行函數聲明，變量聲明，結構體聲明，這也不成問題！！！

那為何一定要分成頭文件與C文件呢？又為何一般都在頭件中進行函數，變量聲明，宏聲明，結構體聲明呢？而在C文件中去進行變量定義，函數實現呢？？原因如下：

1.如果在頭文件中實現一個函數體，那麼如果在多個C文件中引用它，而且又同時編譯多個C文件，将其生成的目标文件連接成一個可執行文件，在每個引用此頭文件的C文件所生成的目标文件中，都有一份這個函數的代碼，如果這段函數又沒有定義成局部函數，那麼在連接時，就會發現多個相同的函數，就會報錯

2.如果在頭文件中定義全局變量，并且将此全局變量賦初值，那麼在多個引用此頭文件的C文件中同樣存在相同變量名的拷貝，關鍵是此變量被賦了初值，所以編譯器就會将此變量放入DATA段，最終在連接階段，會在DATA段中存在多個相同的變量，它無法将這些變量統一成一個變量，也就是僅為此變量分配一個空間，而不是多份空間，假定這個變量在頭文件沒有賦初值，編譯器就會将之放入

BSS段，連接器會對BSS段的多個同名變量僅分配一個存儲空間

3.如果在C文件中聲明宏，結構體，函數等，那麼我要在另一個C文件中引用相應的宏，結構體，就必須再做一次重複的工作，如果我改了一個C文件中的一個聲明，那麼又忘了改其它C文件中的聲明，這不就出了大問題了，程序的邏輯就變成了你不可想象的了，如果把這些公共的東東放在一個頭文件中，想用它的C文件就隻需要引用一個就OK了！！！這樣豈不方便，要改某個聲明的時候，隻需要動一下頭文件就行了

4.在頭文件中聲明結構體，函數等，當你需要将你的代碼封裝成一個庫，讓别人來用你的代碼，你又不想公布源碼，那麼人家如何利用你的庫呢？也就是如何利用你的庫中的各個函數呢？？一種方法是公布源碼，别人想怎麼用就怎麼用，另一種是提供頭文件，别人從頭文件中看你的函數原型，這樣人家才知道如何調用你寫的函數，就如同你調用printf函數一樣，裡面的參數是怎樣的？？你是怎麼知道的？？還不是看人家的頭文件中的相關聲明啊！！！當然這些東東都成了C标準，就算不看人家的頭文件，你一樣可以知道怎麼使用。

C 語言中.c和.h文件的困惑

本質上沒有任何區别。 隻不過一般：.h文件是頭文件，内含函數聲明、宏定義、結構體定義等内容

.c文件是程序文件，内含函數實現，變量定義等内容。而且是什麼後綴也沒有關系，隻不過編譯器會默認對某些後綴的文件采取某些動作。你可以強制編譯器把任何後綴的文件都當作c文件來編。

這樣分開寫成兩個文件是一個良好的編程風格。

而且，比方說 我在aaa.h裡定義了一個函數的聲明，然後我在aaa.h的同一個目錄下建立aaa.c，aaa.c裡定義了這個函數的實現，然後是在main函數所在.c文件裡#include這個aaa.h 然後我就可以使用這個函數了。main在運行時就會找到這個定義了這個函數的aaa.c文件。

這是因為：

main函數為标準C/C 的程序入口，編譯器會先找到該函數所在的文件。

假定編譯程序編譯myproj.c（其中含main()）時，發現它include了mylib.h（其中聲明了函數void test()），那麼此時編譯器将按照事先設定的路徑（Include路徑列表及代碼文件所在的路徑）查找與之同名的實現文件（擴展名為.cpp或.c，此例中為mylib.c），如果找到該文件，并在其中找到該函數（此例中為void test()）的實現代碼，則繼續編譯；如果在指定目錄找不到實現文件，或者在該文件及後續的各include文件中未找到實現代碼，則返回一個編譯錯誤.其實include的過程完全可以"看成"是一個文件拼接的過程，将聲明和實現分别寫在頭文件及C文件中，或者将二者同時寫在頭文件中，理論上沒有本質的區别。

以上是所謂動态方式。

對于靜态方式，基本所有的C/C 編譯器都支持一種鍊接方式被稱為Static Link，即所謂靜态鍊接。

在這種方式下，我們所要做的，就是寫出包含函數，類等等聲明的頭文件（a.h,b.h,...），以及他們對應的實現文件（a.cpp,b.cpp,...），編譯程序會将其編譯為靜态的庫文件（a.lib,b.lib,...）。在随後的代碼重用過程中，我們隻需要提供相應的頭文件（.h）和相應的庫文件（.lib），就可以使用過去的代碼了。

相對動态方式而言，靜态方式的好處是實現代碼的隐蔽性，即C 中提倡的"接口對外，實現代碼不可見"。有利于庫文件的轉發。

如果說難題最難的部分是基本概念，可能很多人都會持反對意見，但實際上也确實如此。我高中的時候學物理，老師抓的重點就是概念--概念一定要搞清，于是難題也成了容易題。如果你能分析清楚一道物理難題存在着幾個物理過程，每一個過程都遵守那一條物理定律(比如動量守恒、牛II定律、能量守恒)，那麼就很輕松的根據定律列出這個過程的方程，N個過程必定是N個N元方程，難題也就迎刃而解。即便是高中的物理競賽難題，最難之處也不過在于：

(1)、混淆你的概念，讓你無法分析出幾個物理過程，或某個物理過程遵循的那條物理定律；

(2)、存在高次方程，列出方程也解不出。而後者已經是數學的範疇了，所以說，最難之處還在于掌握清晰的概念；

程序設計也是如此，如果概念很清晰，那基本上沒什麼難題(會難在數學上，比如算法的選擇、時間空間與效率的取舍、穩定與資源的平衡上)。但是，要掌握清晰的概念也沒那麼容易。比如下面這個例子，看看你有沒有很清晰透徹的認識。

//a.h void foo(); //a.c #include "a.h" //我的問題出來了：這句話是要，還是不要？

void foo()

{ return; } //main.c #include "a.h" int main(int argc, char *argv[]) {foo(); return 0; }

針對上面的代碼，請回答三個問題：

. （1）a.c 中的 #include "a.h" 這句話是不是多餘的？

（2）為什麼經常見 xx.c 裡面 include 對應的 xx.h？

（3）如果 a.c 中不寫，那麼編譯器是不是會自動把 .h 文件裡面的東西跟同名的 .c 文件綁定在一起？（不會）

（請針對上面3道題仔細考慮10分鐘，莫要着急看下面的解釋。:) 考慮的越多，下面理解的就越深。）

好了，時間到！請忘掉上面的3道題，以及對這三道題引發出的你的想法，然後再聽我慢慢道來。正确的概念是：從C編譯器角度看，.h和.c皆是浮雲，就是改名為.txt、.doc也沒有大的分别。換句話說，就是.h和.c沒啥必然聯系。.h中一般放的是同名.c文件中定義的變量、數組、函數的聲明，需要讓.c外部使用的聲明。這個聲明有啥用？隻是讓需要用這些聲明的地方方便引用。因為#include "xx.h" 這個宏其實際意思就是把當前這一行删掉，把 xx.h中的内容原封不動的插入在當前行的位置。由于想寫這些函數聲明的地方非常多（每一個調用 xx.c 中函數的地方，都要在使用前聲明一下子），所以用#include "xx.h" 這個宏就簡化了許多行代碼--讓預處理器自己替換好了。也就是說，xx.h 其實隻是讓需要寫 xx.c中函數聲明的地方調用（可以少寫幾行字），至于 include 這個 .h 文件是誰，是 .h 還是 .c，還是與這個 .h 同名的.c，都沒有任何必然關系。

這樣你可能會說：啊？那我平時隻想調用 xx.c 中的某個函數，卻 include了 xx.h文件，豈不是宏替換後出現了很多無用的聲明？沒錯，确實引入了很多垃圾，但是它卻省了你不少筆墨，并且整個版面也看起來清爽的多。魚與熊掌不可得兼，就是這個道理。反正多些聲明（.h一般隻用來放聲明，而放不定義，參見拙著"過馬路，左右看"）也無害處，又不會影響編譯，何樂而不為呢？

翻回頭再看上面的3個問題，很好解答了吧？答：不一定。這個例子中顯然是多餘的。但是如果.c中的函數也需要調用同個.c中的其它函數，那麼這個.c往往會include同名的.h，這樣就不需要為聲明和調用順序而發愁了（C語言要求使用之前必須聲明，而include同名.h一般會放在.c的開頭）。有很多工程甚至把這種寫法約定為代碼規範，以規範出清晰的代碼來。

答：1中已經回答過了。

答：不會。問這個問題的人絕對是概念不清，要不就是想混水摸魚。非常讨厭的是中國的很多考試出的都是這種爛題，生怕别人有個清楚的概念了，絕對要把考生搞暈。

搞清楚語法和概念說易也易，說難也難。竅門有三點： 不要暈着頭工作，要抽空多思考思考，多看看書；

看書要看好書，問人要問強人。爛書和爛人都會給你一個錯誤的概念，誤導你；

勤能補拙是良訓，一分辛苦一分才；

（1）通過頭文件來調用庫功能。在很多場合，源代碼不便（或不準）向用戶公布，隻要向用戶提供頭文件和二進制的庫即可。用戶隻需要按照頭文件中的接口聲明來調用庫功能，而不必關心接口怎麼實現的。編譯器會從庫中提取相應的代碼。

（2）頭文件能加強類型安全檢查。如果某個接口被實現或被使用時，其方式與頭文件中的聲明不一緻，編譯器就會指出錯誤，這一簡單的規則能大大減輕程序員調試、改錯的負擔。

頭文件用來存放函數原型。

頭文件如何來關聯源文件？

這個問題實際上是說，已知頭文件"a.h"聲明了一系列函數(僅有函數原型,沒有函數實現)，"b.cpp"中實現了這些函數，那麼如果我想在"c.cpp"中使用"a.h"中聲明的這些在"b.cpp"中實現的函數，通常都是在"c.cpp"中使用#include "a.h",那麼c.cpp是怎樣找到b.cpp中的實現呢？

其實.cpp和.h文件名稱沒有任何直接關系，很多編譯器都可以接受其他擴展名。

譚浩強老師的《C程序設計》一書中提到，編譯器預處理時，要對#include命令進行"文件包含處理"：将headfile.h的全部内容複制到#include

"headfile.h"處。這也正說明了，為什麼很多編譯器并不care到底這個文件的後綴名是什麼----因為#include預處理就是完成了一個"複制并插入代碼"的工作。

程序編譯的時候，并不會去找b.cpp文件中的函數實現，隻有在link的時候才進行這個工作。我們在b.cpp或c.cpp中用#include "a.h"實際上是引入相關聲明，使得編譯可以通過，程序并不關心實現是在哪裡，是怎麼實現的。源文件編譯後成生了目标文件（.o或.obj文件），目标文件中，這些函數和變量就視作一個個符号。在link的時候，需要在makefile裡面說明需要連接哪個.o或.obj文件（在這裡是b.cpp生成的.o或.obj文件），此時，連接器會去這個.o或.obj文件中找在b.cpp中實現的函數，再把他們build到makefile中指定的那個可以執行文件中。 （非常重要）

在VC中，一幫情況下不需要自己寫makefile，隻需要将需要的文件都包括在project中，VC會自動幫你把makefile寫好。

通常，編譯器會在每個.o或.obj文件中都去找一下所需要的符号，而不是隻在某個文件中找或者說找到一個就不找了。因此，如果在幾個不同文件中實現了同一個函數，或者定義了同一個全局變量，鍊接的時候就會提示"redefined"。

最後，無論你是在職場成長階段還是在大學入門階段，C/C 都是一個既可以強化思維能力，又可以打好編程基礎的編程語言，你想要做軟件開發，成為核心程序員的話，學習C/C 是比較好的選擇，筆者有一個C/C 的編程千人Q羣（Q艘索：C語言編程學習聚集地（無言建立））你如果感覺自學C/C 語言有困難的話，有興趣學習或者了解一下C/C 編程的夥伴就可以進來交流。下面給大家分享一下C/C 的學習路線圖：

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部