.cs是什麼檔案_C/C++｜頭檔案、源檔案分開寫的源起及作用

1 C/C++ 編譯模式

通常，在一個 C++ 程式中，隻包含兩類檔案—— .cpp 檔案和 .h 檔案。其中，.cpp 檔案被稱作 C++ 源檔案，裡面放的都是 C++ 的源代碼；而 .h 檔案則被稱作 C++ 頭檔案，裡面放的也是 C++ 的源代碼。

C++ 語言支援“分别編譯”(separatecompilation)。也就是說，一個程式所有的内容，可以分成不同的部分分别放在不同的 .cpp 檔案裡。.cpp 檔案裡的東西都是相對獨立的，在編譯(compile)時不需要與其他檔案互通，隻需要在編譯成目标檔案後再與其他的目标檔案做一次連結(link)就行了。比如，在檔案 a.cpp 中定義了一個全局函數 "void a(){}"，而在檔案 b.cpp 中需要調用這個函數。即使這樣，檔案 a.cpp 和檔案 b.cpp 并不需要互相知道對方的存在，而是可以分别地對它們進行編譯，編譯成目标檔案之後再連結，整個程式就可以運作了。

這是怎麼實作的呢？從寫程式的角度來講，很簡單。在檔案 b.cpp 中，在調用 "void a()" 函數之前，先聲明一下這個函數 "void a();"，就可以了。這是因為編譯器在編譯 b.cpp 的時候會生成一個符号表(symbol table)，像 "void a()" 這樣的看不到定義的符号，就會被存放在這個表中。再進行連結的時候，編譯器就會在别的目标檔案(實作檔案)中去尋找這個符号的定義。一旦找到了，程式也就可以順利地生成了，如果找不到，則會産生連結錯誤。

注意這裡提到了兩個概念，一個是"定義"，一個是"聲明"。簡單地說，"定義"就是把一個符号完完整整地描述出來：它是變量還是函數，傳回什麼類型，需要什麼參數等等。而"聲明"則隻是聲明這個符号的存在，即告訴編譯器，這個符号是在其他檔案中定義的，我這裡先用着，你連結的時候再到别的地方去找找看它到底是什麼吧。定義的時候要按 C++ 文法完整地定義一個符号(變量或者函數)，而聲明的時候就隻需要寫出這個符号的原型了。需要注意的是，一個符号，在整個程式中可以被聲明多次，但卻要且僅要被定義一次。試想，如果一個符号出現了兩種不同的定義，編譯器該聽誰的？

這種機制給 C++ 程式員們帶來了很多好處，同時也引出了一種編寫程式的方法。考慮一下，如果有一個很常用的函數 "void f() {}"，在整個程式中的許多 .cpp 檔案中都會被調用，那麼，我們就隻需要在一個檔案中定義這個函數，而在其他的檔案中聲明這個函數就可以了。

2 為什麼C++要分為頭檔案和源檔案？

這是否和外部調用有關？為什麼現在大多數語言都沒有采用這種設計？為什麼調用dll有時需要使用Windows提供的API導出函數或者結構，而不能直接include xxxx.h或者像C#寫的dll那樣在項目中添加引用然後直接using xxxx。

需要從C/C++曆史演變的角度回答下這個問題。

上世紀70年代初，C語言初始版本被設計出來時，是沒有頭檔案的。這一點與後世的Java隻有.java檔案，C#隻有.cs檔案很相似。即使是現代的C編譯器，頭檔案也不是必須的。我使用下面這個例子說明：

//alpha.cint main(){    print_hello();}//beta.cvoid print_hello(){    puts("hello");}
           

上例隻有兩個源檔案，alpha.c與beta.c。其中alpha.c使用了一個自定義函數print_hello，beta.c中使用了标準庫函數puts。注意：alpha.c與beta.c都沒有包含任何頭檔案。

你可以使用MSCL編譯器來編譯：

cl/Fe:program.exealpha.cbeta.c

或者GCC以及Clang：

clang-oprogramalpha.cbeta.c

這樣會得到一個名為program的可執行檔案，并且它可以正常工作。

以beta.c為例：當beta.c被編譯時，編譯器解析到名為puts的符号，雖然它是未定義的，但從文法上可以判斷puts是一個函數，故而将其認定為函數，作為外部符号等待連結就可以了(倘若alpha，beta是C++源檔案，編譯無法通過，這個後文會做解釋)。

下面我用ASCII字元繪制的“編譯”與“連結”流程圖：

alpha.c -> alpha.obj                                                                      program.exe                                /beta.c  -> beta.obj
           

相信這個流程作為基礎知識已廣為人知，我就不再贅述了。問題在于：當初為什麼要采用這樣的設計？将“編譯”、“連結”兩個步驟區分開，并讓使用者可知是什麼意圖？

其實這是上世紀60、70年代各語言的“套路”做法，因為各個obj檔案可能并不是同一種語言源檔案編譯得到的，它們可能來自于C，可能是彙編、也可能是Fortran這樣與C一樣的進階語言。即是說“編譯”、“連結”的流程其實是這樣的：

alpha.c    -> alpha.obj                                       beta.asm   -> beta.obj --> program.exe                                       /gamma.f    -> gamma.obj
           

是以，編譯階段C源檔案(當然也包括其它語言的源檔案)是不與其它源檔案産生關系的，因為編譯器(這裡指的是狹義的編譯器，不包括連結器)本身有可能并不能識别其它源。

說到這裡，定然有人要問：連函數參數和傳回值都不知道，直接連結然後調用，會不會出現問題。答案是：不會，至少當時不會。因為當時的C隻有一種資料類型，即“字長”(同時代的大多數語言也一樣)。

我們考慮這樣一個函數調用：

n=add(1,2,3,4);

首先，add函數的調用者，将4個參數自右向左壓入棧，即是說壓棧完成後1在棧頂，4在棧底；然後，add被調用，對于被調用者(也就是add)而言，棧長度是不可知的，但第一個參數在棧頂，往下一個字長就是第二個參數，以此類推，是以棧長度不可知并不會帶來問題；add處理完成後，将傳回值放入資料寄存器，并傳回；調用者彈棧，因為壓棧操作是調用者實施的，故而棧長度、壓棧前棧頂位置等資訊調用者是可知的，可以調用者有能力保持棧平衡。

這裡說一個題外話：倘若調用者壓棧的參數不夠，那會如何？答案是被調用者會在棧上讀到垃圾資料；又問：倘若被調用者沒有傳回值，那會如何？答案是調用者會在寄存器得到垃圾資料；再問：如此在代碼維護上不會有問題嗎？答案是從後來的實踐上看，問題不大，其實可以對比下如今python、lua等弱類型語言。

通過上面的論述，我們得知C語言設計之初是沒有頭檔案的，調用某個函數也不需要提前聲明。

不過好景不長，後來出現了不同的資料類型。例如出于可移植性和記憶體節省的考慮，出現了short int、long int；為了加強對塊處理的IO裝置的支援，出現了char。如此就帶來了一個問題，即函數的調用者不知道壓棧的長度。例如有函數調用：

add(x,y);

調用者知道add是一個函數，也知道需要将x、y壓棧，但應該是先壓2個位元組、再壓4個位元組喃，還是先壓4個位元組，再壓2個位元組喃；還是連續壓2個4位元組喃？

這裡需要說明一下，在上世紀80年代intel8084系的處理器普及以前，并沒有公認的“位元組(byte)”概念，以上隻是我舉例友善。

緊接着結構體等特性陸續引入，問題變得更複雜。在這種情況下，函數調用需要提前聲明，以便讓調用者得知函數的參數與傳回值尺寸(結構體使用也需要提前聲明，以便讓調用者知道其成員、尺寸、記憶體對其規則等，這裡不贅述了)。

這裡有人可能就會問了：為什麼在編譯一個源檔案時，不去其它源檔案查找聲明，就如後世的Java、C#一樣。主要原因上文已經說過：C源檔案在編譯時不與其它源産生關系，因為其它源可能根本就不是C；此外使用include将聲明插入到源檔案中，技術實作畢竟很簡單，也可以說是一種技術慣性。

又後來出現了C++，由于函數重載、模闆等特性，當編譯器識别到一個函數，不僅是參數與傳回值尺寸，連調用哪一個函數都無法從函數名辨識了(即上文的“倘若alpha，beta是C++源檔案，編譯無法通過，這個後文會做解釋”一語)。函數與資料結構需要提前聲明才能使用更是不可或缺。

對于函數聲明，一個函數還好對付，聲明起來也就一句話。但是，如果函數多了，比如是一大堆的數學函數，有好幾百個，那怎麼辦？能保證每個程式員都可以完完全全地把所有函數的形式都準确地記下來并寫出來嗎？

很顯然，答案是不可能。但是有一個很簡單地辦法，可以幫助程式員們省去記住那麼多函數原型的麻煩：我們可以把那幾百個函數的聲明語句全都先寫好，放在一個檔案裡，等到程式員需要它們的時候，就把這些東西全部 copy 進他的源代碼中。

這個方法固然可行，但還是太麻煩，而且還顯得很笨拙。于是，頭檔案便可以發揮它的作用了。所謂的頭檔案，其實它的内容跟 .cpp 檔案中的内容是一樣的，都是 C++ 的源代碼。但頭檔案不用被編譯。我們把所有的函數聲明全部放進一個頭檔案中，當某一個 .cpp 源檔案需要它們時，它們就可以通過一個宏指令 "#include" 包含進這個 .cpp 檔案中，進而把它們的内容合并到 .cpp 檔案中去。當 .cpp 檔案被編譯時，這些被包含進去的 .h 檔案的作用便發揮了。

舉一個例子吧，假設所有的數學函數隻有兩個：f1 和 f2，那麼我們把它們的定義放在 math.cpp 裡：

/* math.cpp */double f1(){    //do something here....    return;}double f2(double a){    //do something here...    return a * a;}/* end of math.cpp */
           

并把"這些"函數的聲明放在一個頭檔案 math.h 中：

/* math.h */double f1();double f2(double);/* end of math.h */
           

在另一個檔案main.cpp中，我要調用這兩個函數，那麼就隻需要把頭檔案包含進來：

/* main.cpp */#include "math.h"main(){    int number1 = f1();    int number2 = f2(number1);}/* end of main.cpp */
           

這樣，便是一個完整的程式了。需要注意的是，.h 檔案不用寫在編譯器的指令之後，但它必須要在編譯器找得到的地方(比如跟 main.cpp 在一個目錄下)main.cpp 和 math.cpp 都可以分别通過編譯，生成 main.o 和 math.o，然後再把這兩個目标檔案進行連結，程式就可以運作了。

3 #include

#include 是一個來自 C 語言的宏指令，它在編譯器進行編譯之前，即在預編譯的時候就會起作用。#include 的作用是把它後面所寫的那個檔案的内容，完完整整地、一字不改地包含到目前的檔案中來。值得一提的是，它本身是沒有其它任何作用與副功能的，它的作用就是把每一個它出現的地方，替換成它後面所寫的那個檔案的内容。簡單的文本替換，别無其他。是以，main.cpp 檔案中的第一句(#include"math.h")，在編譯之前就會被替換成 math.h 檔案的内容。即在編譯過程将要開始的時候，main.cpp 的内容已經發生了改變：

/* ~main.cpp */double f1();double f2(double);main(){    int number1 = f1();    int number2 = f2(number1);}/* end of ~main.cpp */
           

不多不少，剛剛好。同理可知，如果我們除了 main.cpp 以外，還有其他的很多 .cpp 檔案也用到了 f1 和 f2 函數的話，那麼它們也通通隻需要在使用這兩個函數前寫上一句 #include "math.h" 就行了。

系統自帶的頭檔案用尖括号括起來，這樣編譯器會在系統檔案目錄下查找。

使用者自定義的檔案用雙引号括起來，編譯器首先會在使用者目錄下查找，然後在到 C++ 安裝目錄(比如 VC 中可以指定和修改庫檔案查找路徑，Unix 和 Linux 中可以通過環境變量來設定)中查找，最後在系統檔案中查找。

4 頭檔案如何來關聯源檔案

這個問題實際上是說，已知頭檔案 "a.h" 聲明了一系列函數，"b.cpp" 中實作了這些函數，那麼如果我想在 "c.cpp" 中使用 "a.h" 中聲明的這些在 "b.cpp"中實作的函數，通常都是在 "c.cpp" 中使用 #include "a.h"，那麼 c.cpp 是怎樣找到 b.cpp 中的實作呢？

其實 .cpp 和 .h 檔案名稱沒有任何直接關系，很多編譯器都可以接受其他擴充名。如cpp 檔案用 .cc 擴充名。

在 Turbo C 中，采用指令行方式進行編譯，指令行參數為檔案的名稱，預設的是 .cpp 和 .h，但是也可以自定義為 .xxx 等等。

編譯器預處理時，要對 #include 指令進行"檔案包含處理"，這也正說明了，為什麼很多編譯器并不 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 中指定的那個可以執行檔案中。

在 Unix下，甚至可以不在源檔案中包括頭檔案，隻需要在 makefile 中指名即可(不過這樣大大降低了程式可讀性，是個不好的習慣)。在 VC 中，一般情況下不需要自己寫 makefile，隻需要将需要的檔案都包括在 project中，VC 會自動幫你把 makefile 寫好。

通常，C++ 編譯器會在每個 .o 或 .obj 檔案中都去找一下所需要的符号，而不是隻在某個檔案中找或者說找到一個就不找了。是以，如果在幾個不同檔案中實作了同一個函數，或者定義了同一個全局變量，連結的時候就會提示 "redefined"。

5 頭檔案實作了接口的功能

函數的聲明寫在頭檔案中，實作放在源檔案中，以及分開編譯的機制，對于函數的使用者來說，隻需通過頭檔案便可知道有哪些函數可供使用以及如何使用，而無需關注其實作的具體細節。對于函數的實作者來說，一方面可以隐藏函數的實作，另一方面，更新函數的實作也無須使用者修改其調用函數的代碼，也就是說，隻是保持頭檔案(接口)的穩定性，而具體實作可以随時更新，不會對函數使用者産生影響。

6、頭檔案中應該寫什麼

通過上面的讨論，我們可以了解到，頭檔案的作用就是被其他的 .cpp 包含進去的。它們本身并不參與編譯，但實際上，它們的内容卻在多個 .cpp 檔案中得到了編譯。通過"定義隻能有一次"的規則，我們很容易可以得出，頭檔案中應該隻放變量和函數的聲明，而不能放它們的定義。因為一個頭檔案的内容實際上是會被引入到多個不同的 .cpp 檔案中的，并且它們都會被編譯。放聲明當然沒事，如果放了定義，那麼也就相當于在多個檔案中出現了對于一個符号(變量或函數)的定義，縱然這些定義都是相同的，但對于編譯器來說，這樣做不合法。

是以，應該記住的一點就是，.h頭檔案中，隻能存在變量或者函數的聲明，而不要放定義。即，隻能在頭檔案中寫形如：extern int a; 和 void f(); 的句子。這些才是聲明。如果寫上 int a;或者 void f() {} 這樣的句子，那麼一旦這個頭檔案被兩個或兩個以上的 .cpp 檔案包含的話，編譯器會立馬報錯。

但是，這個規則是有三個例外的:

6.1 頭檔案中可以寫 const 對象的定義。因為全局的 const 對象預設是沒有 extern 的聲明的，是以它隻在目前檔案中有效。把這樣的對象寫進頭檔案中，即使它被包含到其他多個 .cpp 檔案中，這個對象也都隻在包含它的那個檔案中有效，對其他檔案來說是不可見的，是以便不會導緻多重定義。同時，因為這些 .cpp 檔案中的該對象都是從一個頭檔案中包含進去的，這樣也就保證了這些 .cpp 檔案中的這個 const 對象的值是相同的，可謂一舉兩得。同理，static 對象的定義也可以放進頭檔案。

6.2 頭檔案中可以寫内聯函數(inline)的定義。因為inline函數是需要編譯器在遇到它的地方根據它的定義把它内聯展開的，而并非是普通函數那樣可以先聲明再連結的(内聯函數不會連結)，是以編譯器就需要在編譯時看到内聯函數的完整定義才行。如果内聯函數像普通函數一樣隻能定義一次的話，這事兒就難辦了。因為在一個檔案中還好，我可以把内聯函數的定義寫在最開始，這樣可以保證後面使用的時候都可以見到定義；但是，如果我在其他的檔案中還使用到了這個函數那怎麼辦呢？這幾乎沒什麼太好的解決辦法，是以 C++ 規定，内聯函數可以在程式中定義多次，隻要内聯函數在一個 .cpp 檔案中隻出現一次，并且在所有的 .cpp 檔案中，這個内聯函數的定義是一樣的，就能通過編譯。那麼顯然，把内聯函數的定義放進一個頭檔案中是非常明智的做法。

6.3 頭檔案中可以寫類(class)的定義。因為在程式中建立一個類的對象時，編譯器隻有在這個類的定義完全可見的情況下，才能知道這個類的對象應該如何布局，是以，關于類的定義的要求，跟内聯函數是基本一樣的。是以把類的定義放進頭檔案，在使用到這個類的 .cpp 檔案中去包含這個頭檔案，是一個很好的做法。在這裡，值得一提的是，類的定義中包含着資料成員和函數成員。資料成員是要等到具體的對象被建立時才會被定義(配置設定空間)，但函數成員卻是需要在一開始就被定義的，這也就是我們通常所說的類的實作。一般，我們的做法是，把類的定義放在頭檔案中，而把函數成員的實作代碼放在一個 .cpp 檔案中。這是可以的，也是很好的辦法。不過，還有另一種辦法。那就是直接把函數成員的實作代碼也寫進類定義裡面。在 C++ 的類中，如果函數成員在類的定義體中被定義，那麼編譯器會視這個函數為内聯的。是以，把函數成員的定義寫進類定義體，一起放進頭檔案中，是合法的。注意一下，如果把函數成員的定義寫在類定義的頭檔案中，而沒有寫進類定義中，這是不合法的，因為這個函數成員此時就不是内聯的了。一旦頭檔案被兩個或兩個以上的 .cpp 檔案包含，這個函數成員就被重定義了。

綜上所述，.h檔案可以包含：

函數的聲明；

靜态函數的定義；

結構體的聲明；

類成員資料的聲明，但不能指派；

類靜态資料成員的定義和指派，但不建議，隻是個聲明就好；

類的成員函數的聲明；

非類成員函數的聲明；

常數的定義：如：constint a=5;

類的内聯函數的定義；

不能包含：

所有非靜态變量(不是類的資料成員)的聲明(對于C來說，除了extern，聲明就是定義)；

預設命名空間聲明不要放在頭檔案，using namespace std;等應放在.cpp中，在 .h 檔案中使用 std::string；

7 頭檔案中的保護措施

考慮一下，如果頭檔案中隻包含聲明語句的話，它被同一個 .cpp 檔案包含再多次都沒問題——因為聲明語句的出現是不受限制的。然而，上面讨論到的頭檔案中的三個例外也是頭檔案很常用的一個用處。那麼，一旦一個頭檔案中出現了上面三個例外中的任何一個，它再被一個 .cpp 包含多次的話，問題就大了。因為這三個例外中的文法元素雖然"可以定義在多個源檔案中"，但是"在一個源檔案中隻能出現一次"。設想一下，如果 a.h 中含有類 A 的定義，b.h 中含有類 B 的定義，由于類B的定義依賴了類 A，是以 b.h 中也 #include了a.h。現在有一個源檔案，它同時用到了類A和類B，于是程式員在這個源檔案中既把 a.h 包含進來了，也把 b.h 包含進來了。這時，問題就來了：類A的定義在這個源檔案中出現了兩次！于是整個程式就不能通過編譯了。你也許會認為這是程式員的失誤——他應該知道 b.h 包含了 a.h ——但事實上他不應該知道。

使用 "#define" 配合條件編譯可以很好地解決這個問題。在一個頭檔案中，通過 #define 定義一個名字，并且通過條件編譯 #ifndef...#endif 使得編譯器可以根據這個名字是否被定義，再決定要不要繼續編譯該頭文中後續的内容。這個方法雖然簡單，但是寫頭檔案時一定記得寫進去。

－End－