C/C++編譯和連結過程詳解 (重定向表，匯出符號表，未解決符號表)
阿新 • • 發佈：2019-01-28
詳解link
有 些人寫C/C++(以下假定為C++)程式，對unresolved external link或者duplicated external simbol的錯誤資訊不知所措（因為這樣的錯誤資訊不能定位到某一行）。或者對語言的一些部分不知道為什麼要（或者不要）這樣那樣設計。瞭解本文之後， 或許會有一些答案。
首先看看我們是如何寫一個程式的。如果你在使用某種IDE（Visual Studio，Elicpse，Dev C++等），你可能不會發現程式是如何組織起來的（很多人因此而反對初學者使用IDE）。因為使用IDE，你所做的事情，就是在一個專案裡新建一系列 的.cpp和.h檔案，編寫好之後在選單裡點選“編譯”，就萬事大吉了。但其實以前，程式設計師寫程式不是這樣的。他們首先要開啟一個編輯器，像編寫文字檔案 一樣的寫好程式碼，然後在命令列下敲
cc 1.cpp -o 1.o
cc 2.cpp -o 2.o
cc 3.cpp -o 3.o
這裡cc代表某個C/C++編譯器，後面緊跟著要編譯的cpp檔案，並且以-o指定要輸出的檔案（請原諒我沒有使用任何一個流行編譯器作為例子）。這樣當前目錄下就會出現：
1.o 2.o 3.o
最後，程式設計師還要鍵入
link 1.o 2.o 3.o -o a.out
來生成最終的可執行檔案a.out。現在的IDE，其實也同樣遵照著這個步驟，只不過把一切都自動化了。
讓我們來分析上面的過程，看看能發現什麼。
首先，對原始碼進行編譯，是對各個cpp檔案單獨進行的。對於每一次編譯，如果排除在cpp檔案裡include別的cpp檔案的情況（這是C++程式碼編 寫中極其錯誤的寫法），那麼編譯器僅僅知道當前要編譯的那一個cpp檔案，對其他的cpp檔案的存在完全不知情。
其次，每個cpp檔案編譯後，產生的.o檔案，要被一個連結器(link)所讀入，才能最終生成可執行檔案。
好了，有了這些感性認識之後，讓我們來看看C/C++程式是如何組織的。
首先要知道一些概念：
編譯：編譯器對原始碼進行編譯，是將以文字形式存在的原始碼翻譯為機器語言形式的目標檔案的過程。
編譯單元：對於C++來說，每一個cpp檔案就是一個編譯單元。從之前的編譯過程的演示可以看出，各個編譯單元之間是互相不可知的。
目標檔案：由編譯所生成的檔案，以機器碼的形式包含了編譯單元裡所有的程式碼和資料，以及一些其他的資訊。
下面我們具體看看編譯的過程。我們跳過語法分析等，直接來到目標檔案的生成。假設我們有一個1.cpp檔案
int n = 1;
void f()
{
++n;
}
它編譯出來的目標檔案1.o就會有一個區域（假定名稱為2進位制段），包含了以上資料／函式，其中有n, f，以檔案偏移量的形式給出很可能就是：
偏移量 內容 長度
0x000 n 4
0x004 f ??
注意：這僅僅是猜測，不代表目標檔案的真實佈局。目標檔案的各個資料不一定連續，也不一定按照這個順序，當然也不一定從0x000開始。
現在我們看看從0x004開始f函式的內容（在0x86平臺下的猜測）：
0x004 inc DWORD PTR [0x000]
0x00? ret
注意n++已經被翻譯為：inc DWORD PTR [0x000]，也就是把本單元0x000位置上的一個DWORD(4位元組)加1。
下面如果有另一個2.cpp，如下
extern int n;
void g()
{
++n;
}
那麼它的目標檔案2.o的2進位制段就應該是
偏移量 內容 長度
0x000 g ??
為什麼這裡沒有n的空間（也就是n的定義），因為n被宣告為extern，表明n的定義在別的編譯單元裡。別忘了編譯的時候是不可能知道別的編譯單元的情 況的，故編譯器不知道n究竟在何處，所以這個時候g的二進位制程式碼裡沒有辦法填寫inc DWORD PTR [???]中的？？？部分。怎麼辦呢？這個工作就只能交給後來的連結器去處理。為了讓連結器知道哪些地方的地址是沒有填好的，所以目標檔案還要有一個“未 解決符號表”，也就是unresolved symbol table. 同樣,提供n的定義的目標檔案(也就是1.o)也要提供一個“匯出符號表”，export symbol table, 來告訴連結器自己可以提供哪些地址。
讓我們理一下思路：現在我們知道，每一個目標檔案，除了擁有自己的資料和二進位制程式碼之外，還要至少提供2個表：未解決符號表和匯出符號表，分別告訴連結器 自己需要什麼和能夠提供什麼。下面的問題是，如何在2個表之間建立對應關係。這裡就有一個新的概念：符號。在C/C++中，每一個變數和函式都有自己的符 號。例如變數n的符號就是“n”。函式的符號要更加複雜，它需要結合函式名及其引數和呼叫慣例等，得到一個唯一的字串。f的符號可能就是"_f"（根據 不同編譯器可以有變化）。
所以，1.o的匯出符號表就是
符號 地址
n 0x000
_f 0x004
而未解決符號表為空
2.o的匯出符號表為
符號 地址
_g 0x000
未解決符號表為
符號 地址
n 0x001
這裡0x001為從0x000開始的inc DWORD PTR [???]的二進位制編碼中儲存???的起始地址(這裡假設inc的機器碼的第2－5位元組為要+1的絕對地址，需要知道確切情況可查手冊)。這個表告訴連結 器，在本編譯單元0x001的位置上有一個地址，該地址值不明，但是具有符號n。
連結的時候，連結器在2.o裡發現了未解決符號n，那麼在查詢所有編譯單元的時候，在1.o中發現了匯出符號n，那麼連結器就會將n的地址0x000填寫到2.o的0x001的位置上。
“打住”，可能你就會跳出來指責我了。如果這樣做得話，豈不是g的內容就會變成inc DWORD PTR [0x000]，按照之前的理解，這是將本單元的0x000地址的4位元組加1，而不是將1.o的對應位置加1。是的，因為每個編譯單元的地址都是從0開始 的，所以最終拼接起來的時候地址會重複。所以連結器會在拼接的時候對各個單元的地址進行調整。這個例子中，假設2.o的0x00000000地址被定位在 可執行檔案的0x00001000上，而1.o的0x00000000地址被定位在可執行檔案的0x00002000上，那麼實際上對連結器來說，1.o 的匯出符號表其實
符號 地址
n 0x000 + 0x2000
_f 0x004 + 0x2000
而未解決符號表為空
2.o的匯出符號表為
符號 地址
_g 0x000 + 0x1000
未解決符號表為
符號 地址
n 0x001 + 0x1000
所以最終g的程式碼會變為inc DWORD PTR [0x000 + 0x2000]。
最後還有一個漏洞，既然最後n的地址變為0x2000了，那麼以前f的程式碼inc DWORD PTR [0x000]就是錯誤的了。所以目標檔案為此還要提供一個表，叫做地址重定向表address redirect table。
對於1.o來說，它的重定向表為
地址
0x005
這個表不需要符號，當連結器處理這個表的時候，發現地址為0x005的位置上有一個地址需要重定向，那麼直接在以0x005開始的4個位元組上加上0x2000就可以了。
讓我們總結一下：編譯器把一個cpp編譯為目標檔案的時候，除了要在目標檔案裡寫入cpp裡包含的資料和程式碼，還要至少提供3個表：未解決符號表，匯出符號表和地址重定向表。
未解決符號表提供了所有在該編譯單元裡引用但是定義並不在本編譯單元裡的符號及其出現的地址。
匯出符號表提供了本編譯單元具有定義，並且願意提供給其他編譯單元使用的符號及其地址。
地址重定向表提供了本編譯單元所有對自身地址的引用的記錄。
連結器進行連結的時候，首先決定各個目標檔案在最終可執行檔案裡的位置。然後訪問所有目標檔案的地址重定向表，對其中記錄的地址進行重定向（即加上該編譯 單元實際在可執行檔案裡的起始地址）。然後遍歷所有目標檔案的未解決符號表，並且在所有的匯出符號表裡查詢匹配的符號，並在未解決符號表中所記錄的位置上 填寫實際的地址（也要加上擁有該符號定義的編譯單元實際在可執行檔案裡的起始地址）。最後把所有的目標檔案的內容寫在各自的位置上，再作一些別的工作，一 個可執行檔案就出爐了。
最終link 1.o 2.o .... 所生成的可執行檔案大概是
0x00000000 ????（別的一些資訊）
....
0x00001000 inc DWORD PTR [0x00002000] //這裡是2.o的開始，也就是g的定義
0x00001005 ret //假設inc為5個位元組，這裡是g的結尾
....
0x00002000 0x00000001 //這裡是1.o的開始，也是n的定義（初始化為1）
0x00002004 inc DWORD PTR [0x00002000] //這裡是f的開始
0x00002009 ret //假設inc為5個位元組，這裡是f的結尾
...
...
實際連結的時候更為複雜，因為實際的目標檔案裡把資料／程式碼分為好幾個區，重定向等要按區進行，但原理是一樣的。
現在我們可以來看看幾個經典的連結錯誤了：
unresolved external link..
這個很顯然，是連結器發現一個未解決符號，但是在匯出符號表裡沒有找到對應的項。
解決方案麼，當然就是在某個編譯單元裡提供這個符號的定義就行了。（注意，這個符號可以是一個變數，也可以是一個函式），也可以看看是不是有什麼該連結的檔案沒有連結
duplicated external simbols...
這個則是匯出符號表裡出現了重複項，因此連結器無法確定應該使用哪一個。這可能是使用了重複的名稱，也可能有別的原因。
我們再來看看C/C++語言裡針對這一些而提供的特性：
extern:這是告訴編譯器，這個符號在別的編譯單元裡定義，也就是要把這個符號放到未解決符號表裡去。（外部連結）
static:如果該關鍵字位於全域性函式或者變數的宣告的前面，表明該編譯單元不匯出這個函式／變數的符號。因此無法在別的編譯單元裡使用。（內部連結）。如果是static區域性變數，則該變數的儲存方式和全域性變數一樣，但是仍然不匯出符號。
預設連結屬性：對於函式和變數，模認外部連結，對於const變數，預設內部連結。（可以通過新增extern和static改變連結屬性）
外部連結的利弊：外部連結的符號，可以在整個程式範圍內使用（因為匯出了符號）。但是同時要求其他的編譯單元不能匯出相同的符號（不然就是duplicated external simbols)
內部連結的利弊：內部連結的符號，不能在別的編譯單元內使用。但是不同的編譯單元可以擁有同樣名稱的內部連結符號。
為什麼標頭檔案裡一般只可以有宣告不能有定義：標頭檔案可以被多個編譯單元包含，如果標頭檔案裡有定義，那麼每個包含這個標頭檔案的編譯單元就都會對同一個符號 進行定義，如果該符號為外部連結，則會導致duplicated external simbols。因此如果標頭檔案裡要定義，必須保證定義的符號只能具有內部連結。
為什麼常量預設為內部連結，而變數不是：
這就是為了能夠在標頭檔案裡如const int n = 0這樣的定義常量。由於常量是隻讀的，因此即使每個編譯單元都擁有一份定義也沒有關係。如果一個定義於標頭檔案裡的變數擁有內部連結，那麼如果出現多個編譯 單元都定義該變數，則其中一個編譯單元對該變數進行修改，不會影響其他單元的同一變數，會產生意想不到的後果。
為什麼函式預設是外部連結：
雖然函式是隻讀的，但是和變數不同，函式在程式碼編寫的時候非常容易變化，如果函式預設具有內部連結，則人們會傾向於把函式定義在標頭檔案裡，那麼一旦函式 被修改，所有包含了該標頭檔案的編譯單元都要被重新編譯。另外，函式裡定義的靜態區域性變數也將被定義在標頭檔案裡。
為什麼類的靜態變數不可以就地初始化：所謂就地初始化就是類似於這樣的情況：
class A
{
static char msg[] = "aha";
};
不允許這樣做得原因是，由於class的宣告通常是在標頭檔案裡，如果允許這樣做，其實就相當於在標頭檔案裡定義了一個非const變數。
在C++裡，標頭檔案定義一個const物件會怎麼樣：
一般不會怎麼樣，這個和C裡的在標頭檔案裡定義const int一樣，每一個包含了這個標頭檔案的編譯單元都會定義這個物件。但由於該物件是const的，所以沒什麼影響。但是：有2種情況可能破壞這個局面：
1。如果涉及到對這個const物件取地址並且依賴於這個地址的唯一性，那麼在不同的編譯單元裡，取到的地址可以不同。（但一般很少這麼做）
2。如果這個物件具有mutable的變數，某個編譯單元對其進行修改，則同樣不會影響到別的編譯單元。
為什麼類的靜態常量也不可以就地初始化：
因為這相當於在標頭檔案裡定義了const物件。作為例外，int/char等可以進行就地初始化，是因為這些變數可以直接被優化為立即數，就和巨集一樣。
行內函數：
C++裡的行內函數由於類似於一個巨集，因此不存在連結屬性問題。
為什麼公共使用的行內函數要定義於標頭檔案裡：
因為編譯時編譯單元之間互相不知道，如果行內函數被定義於.cpp檔案中，編譯其他使用該函式的編譯單元的時候沒有辦法找到函式的定義，因此無法對函式進行展開。所以說如果行內函數定義於.cpp檔案裡，那麼就只有這個cpp檔案可以是用這個函式。
標頭檔案裡行內函數被拒絕會怎樣：
如果定義於標頭檔案裡的行內函數被拒絕，那麼編譯器會自動在每個包含了該標頭檔案的編譯單元裡定義這個函式並且不匯出符號。
如果被拒絕的行內函數裡定義了靜態區域性變數，這個變數會被定義於何處：
早期的編譯器會在每個編譯單元裡定義一個，並因此產生錯誤的結果，較新的編譯器會解決這個問題，手段未知。
為什麼export關鍵字沒人實現：
export要求編譯器跨編譯單元查詢函式定義，使得編譯器實現非常困難。
有 些人寫C/C++(以下假定為C++)程式，對unresolved external link或者duplicated external simbol的錯誤資訊不知所措（因為這樣的錯誤資訊不能定位到某一行）。或者對語言的一些部分不知道為什麼要（或者不要）這樣那樣設計。瞭解本文之後， 或許會有一些答案。
首先看看我們是如何寫一個程式的。如果你在使用某種IDE（Visual Studio，Elicpse，Dev C++等），你可能不會發現程式是如何組織起來的（很多人因此而反對初學者使用IDE）。因為使用IDE，你所做的事情，就是在一個專案裡新建一系列 的.cpp和.h檔案，編寫好之後在選單裡點選“編譯”，就萬事大吉了。但其實以前，程式設計師寫程式不是這樣的。他們首先要開啟一個編輯器，像編寫文字檔案 一樣的寫好程式碼，然後在命令列下敲
cc 1.cpp -o 1.o
cc 2.cpp -o 2.o
cc 3.cpp -o 3.o
這裡cc代表某個C/C++編譯器，後面緊跟著要編譯的cpp檔案，並且以-o指定要輸出的檔案（請原諒我沒有使用任何一個流行編譯器作為例子）。這樣當前目錄下就會出現：
1.o 2.o 3.o
最後，程式設計師還要鍵入
link 1.o 2.o 3.o -o a.out
來生成最終的可執行檔案a.out。現在的IDE，其實也同樣遵照著這個步驟，只不過把一切都自動化了。
讓我們來分析上面的過程，看看能發現什麼。
首先，對原始碼進行編譯，是對各個cpp檔案單獨進行的。對於每一次編譯，如果排除在cpp檔案裡include別的cpp檔案的情況（這是C++程式碼編 寫中極其錯誤的寫法），那麼編譯器僅僅知道當前要編譯的那一個cpp檔案，對其他的cpp檔案的存在完全不知情。
其次，每個cpp檔案編譯後，產生的.o檔案，要被一個連結器(link)所讀入，才能最終生成可執行檔案。
好了，有了這些感性認識之後，讓我們來看看C/C++程式是如何組織的。
首先要知道一些概念：
編譯：編譯器對原始碼進行編譯，是將以文字形式存在的原始碼翻譯為機器語言形式的目標檔案的過程。
編譯單元：對於C++來說，每一個cpp檔案就是一個編譯單元。從之前的編譯過程的演示可以看出，各個編譯單元之間是互相不可知的。
目標檔案：由編譯所生成的檔案，以機器碼的形式包含了編譯單元裡所有的程式碼和資料，以及一些其他的資訊。
下面我們具體看看編譯的過程。我們跳過語法分析等，直接來到目標檔案的生成。假設我們有一個1.cpp檔案
int n = 1;
void f()
{
++n;
}
它編譯出來的目標檔案1.o就會有一個區域（假定名稱為2進位制段），包含了以上資料／函式，其中有n, f，以檔案偏移量的形式給出很可能就是：
偏移量 內容 長度
0x000 n 4
0x004 f ??
注意：這僅僅是猜測，不代表目標檔案的真實佈局。目標檔案的各個資料不一定連續，也不一定按照這個順序，當然也不一定從0x000開始。
現在我們看看從0x004開始f函式的內容（在0x86平臺下的猜測）：
0x004 inc DWORD PTR [0x000]
0x00? ret
注意n++已經被翻譯為：inc DWORD PTR [0x000]，也就是把本單元0x000位置上的一個DWORD(4位元組)加1。
下面如果有另一個2.cpp，如下
extern int n;
void g()
{
++n;
}
那麼它的目標檔案2.o的2進位制段就應該是
偏移量 內容 長度
0x000 g ??
為什麼這裡沒有n的空間（也就是n的定義），因為n被宣告為extern，表明n的定義在別的編譯單元裡。別忘了編譯的時候是不可能知道別的編譯單元的情 況的，故編譯器不知道n究竟在何處，所以這個時候g的二進位制程式碼裡沒有辦法填寫inc DWORD PTR [???]中的？？？部分。怎麼辦呢？這個工作就只能交給後來的連結器去處理。為了讓連結器知道哪些地方的地址是沒有填好的，所以目標檔案還要有一個“未 解決符號表”，也就是unresolved symbol table. 同樣,提供n的定義的目標檔案(也就是1.o)也要提供一個“匯出符號表”，export symbol table, 來告訴連結器自己可以提供哪些地址。
讓我們理一下思路：現在我們知道，每一個目標檔案，除了擁有自己的資料和二進位制程式碼之外，還要至少提供2個表：未解決符號表和匯出符號表，分別告訴連結器 自己需要什麼和能夠提供什麼。下面的問題是，如何在2個表之間建立對應關係。這裡就有一個新的概念：符號。在C/C++中，每一個變數和函式都有自己的符 號。例如變數n的符號就是“n”。函式的符號要更加複雜，它需要結合函式名及其引數和呼叫慣例等，得到一個唯一的字串。f的符號可能就是"_f"（根據 不同編譯器可以有變化）。
所以，1.o的匯出符號表就是
符號 地址
n 0x000
_f 0x004
而未解決符號表為空
2.o的匯出符號表為
符號 地址
_g 0x000
未解決符號表為
符號 地址
n 0x001
這裡0x001為從0x000開始的inc DWORD PTR [???]的二進位制編碼中儲存???的起始地址(這裡假設inc的機器碼的第2－5位元組為要+1的絕對地址，需要知道確切情況可查手冊)。這個表告訴連結 器，在本編譯單元0x001的位置上有一個地址，該地址值不明，但是具有符號n。
連結的時候，連結器在2.o裡發現了未解決符號n，那麼在查詢所有編譯單元的時候，在1.o中發現了匯出符號n，那麼連結器就會將n的地址0x000填寫到2.o的0x001的位置上。
“打住”，可能你就會跳出來指責我了。如果這樣做得話，豈不是g的內容就會變成inc DWORD PTR [0x000]，按照之前的理解，這是將本單元的0x000地址的4位元組加1，而不是將1.o的對應位置加1。是的，因為每個編譯單元的地址都是從0開始 的，所以最終拼接起來的時候地址會重複。所以連結器會在拼接的時候對各個單元的地址進行調整。這個例子中，假設2.o的0x00000000地址被定位在 可執行檔案的0x00001000上，而1.o的0x00000000地址被定位在可執行檔案的0x00002000上，那麼實際上對連結器來說，1.o 的匯出符號表其實
符號 地址
n 0x000 + 0x2000
_f 0x004 + 0x2000
而未解決符號表為空
2.o的匯出符號表為
符號 地址
_g 0x000 + 0x1000
未解決符號表為
符號 地址
n 0x001 + 0x1000
所以最終g的程式碼會變為inc DWORD PTR [0x000 + 0x2000]。
最後還有一個漏洞，既然最後n的地址變為0x2000了，那麼以前f的程式碼inc DWORD PTR [0x000]就是錯誤的了。所以目標檔案為此還要提供一個表，叫做地址重定向表address redirect table。
對於1.o來說，它的重定向表為
地址
0x005
這個表不需要符號，當連結器處理這個表的時候，發現地址為0x005的位置上有一個地址需要重定向，那麼直接在以0x005開始的4個位元組上加上0x2000就可以了。
讓我們總結一下：編譯器把一個cpp編譯為目標檔案的時候，除了要在目標檔案裡寫入cpp裡包含的資料和程式碼，還要至少提供3個表：未解決符號表，匯出符號表和地址重定向表。
未解決符號表提供了所有在該編譯單元裡引用但是定義並不在本編譯單元裡的符號及其出現的地址。
匯出符號表提供了本編譯單元具有定義，並且願意提供給其他編譯單元使用的符號及其地址。
地址重定向表提供了本編譯單元所有對自身地址的引用的記錄。
連結器進行連結的時候，首先決定各個目標檔案在最終可執行檔案裡的位置。然後訪問所有目標檔案的地址重定向表，對其中記錄的地址進行重定向（即加上該編譯 單元實際在可執行檔案裡的起始地址）。然後遍歷所有目標檔案的未解決符號表，並且在所有的匯出符號表裡查詢匹配的符號，並在未解決符號表中所記錄的位置上 填寫實際的地址（也要加上擁有該符號定義的編譯單元實際在可執行檔案裡的起始地址）。最後把所有的目標檔案的內容寫在各自的位置上，再作一些別的工作，一 個可執行檔案就出爐了。
最終link 1.o 2.o .... 所生成的可執行檔案大概是
0x00000000 ????（別的一些資訊）
....
0x00001000 inc DWORD PTR [0x00002000] //這裡是2.o的開始，也就是g的定義
0x00001005 ret //假設inc為5個位元組，這裡是g的結尾
....
0x00002000 0x00000001 //這裡是1.o的開始，也是n的定義（初始化為1）
0x00002004 inc DWORD PTR [0x00002000] //這裡是f的開始
0x00002009 ret //假設inc為5個位元組，這裡是f的結尾
...
...
實際連結的時候更為複雜，因為實際的目標檔案裡把資料／程式碼分為好幾個區，重定向等要按區進行，但原理是一樣的。
現在我們可以來看看幾個經典的連結錯誤了：
unresolved external link..
這個很顯然，是連結器發現一個未解決符號，但是在匯出符號表裡沒有找到對應的項。
解決方案麼，當然就是在某個編譯單元裡提供這個符號的定義就行了。（注意，這個符號可以是一個變數，也可以是一個函式），也可以看看是不是有什麼該連結的檔案沒有連結
duplicated external simbols...
這個則是匯出符號表裡出現了重複項，因此連結器無法確定應該使用哪一個。這可能是使用了重複的名稱，也可能有別的原因。
我們再來看看C/C++語言裡針對這一些而提供的特性：
extern:這是告訴編譯器，這個符號在別的編譯單元裡定義，也就是要把這個符號放到未解決符號表裡去。（外部連結）
static:如果該關鍵字位於全域性函式或者變數的宣告的前面，表明該編譯單元不匯出這個函式／變數的符號。因此無法在別的編譯單元裡使用。（內部連結）。如果是static區域性變數，則該變數的儲存方式和全域性變數一樣，但是仍然不匯出符號。
預設連結屬性：對於函式和變數，模認外部連結，對於const變數，預設內部連結。（可以通過新增extern和static改變連結屬性）
外部連結的利弊：外部連結的符號，可以在整個程式範圍內使用（因為匯出了符號）。但是同時要求其他的編譯單元不能匯出相同的符號（不然就是duplicated external simbols)
內部連結的利弊：內部連結的符號，不能在別的編譯單元內使用。但是不同的編譯單元可以擁有同樣名稱的內部連結符號。
為什麼標頭檔案裡一般只可以有宣告不能有定義：標頭檔案可以被多個編譯單元包含，如果標頭檔案裡有定義，那麼每個包含這個標頭檔案的編譯單元就都會對同一個符號 進行定義，如果該符號為外部連結，則會導致duplicated external simbols。因此如果標頭檔案裡要定義，必須保證定義的符號只能具有內部連結。
為什麼常量預設為內部連結，而變數不是：
這就是為了能夠在標頭檔案裡如const int n = 0這樣的定義常量。由於常量是隻讀的，因此即使每個編譯單元都擁有一份定義也沒有關係。如果一個定義於標頭檔案裡的變數擁有內部連結，那麼如果出現多個編譯 單元都定義該變數，則其中一個編譯單元對該變數進行修改，不會影響其他單元的同一變數，會產生意想不到的後果。
為什麼函式預設是外部連結：
雖然函式是隻讀的，但是和變數不同，函式在程式碼編寫的時候非常容易變化，如果函式預設具有內部連結，則人們會傾向於把函式定義在標頭檔案裡，那麼一旦函式 被修改，所有包含了該標頭檔案的編譯單元都要被重新編譯。另外，函式裡定義的靜態區域性變數也將被定義在標頭檔案裡。
為什麼類的靜態變數不可以就地初始化：所謂就地初始化就是類似於這樣的情況：
class A
{
static char msg[] = "aha";
};
不允許這樣做得原因是，由於class的宣告通常是在標頭檔案裡，如果允許這樣做，其實就相當於在標頭檔案裡定義了一個非const變數。
在C++裡，標頭檔案定義一個const物件會怎麼樣：
一般不會怎麼樣，這個和C裡的在標頭檔案裡定義const int一樣，每一個包含了這個標頭檔案的編譯單元都會定義這個物件。但由於該物件是const的，所以沒什麼影響。但是：有2種情況可能破壞這個局面：
1。如果涉及到對這個const物件取地址並且依賴於這個地址的唯一性，那麼在不同的編譯單元裡，取到的地址可以不同。（但一般很少這麼做）
2。如果這個物件具有mutable的變數，某個編譯單元對其進行修改，則同樣不會影響到別的編譯單元。
為什麼類的靜態常量也不可以就地初始化：
因為這相當於在標頭檔案裡定義了const物件。作為例外，int/char等可以進行就地初始化，是因為這些變數可以直接被優化為立即數，就和巨集一樣。
行內函數：
C++裡的行內函數由於類似於一個巨集，因此不存在連結屬性問題。
為什麼公共使用的行內函數要定義於標頭檔案裡：
因為編譯時編譯單元之間互相不知道，如果行內函數被定義於.cpp檔案中，編譯其他使用該函式的編譯單元的時候沒有辦法找到函式的定義，因此無法對函式進行展開。所以說如果行內函數定義於.cpp檔案裡，那麼就只有這個cpp檔案可以是用這個函式。
標頭檔案裡行內函數被拒絕會怎樣：
如果定義於標頭檔案裡的行內函數被拒絕，那麼編譯器會自動在每個包含了該標頭檔案的編譯單元裡定義這個函式並且不匯出符號。
如果被拒絕的行內函數裡定義了靜態區域性變數，這個變數會被定義於何處：
早期的編譯器會在每個編譯單元裡定義一個，並因此產生錯誤的結果，較新的編譯器會解決這個問題，手段未知。
為什麼export關鍵字沒人實現：
export要求編譯器跨編譯單元查詢函式定義，使得編譯器實現非常困難。