匿名 Namespace和static 的區別


C++的鏈接性質,也就是translation unit的作用范圍。

  1. 在C中,給全局變量,函數,加上 static,表示當前函數和變量的linkage 為 internal,這樣,就可以在不同的unit 中定義同名的函數和變量了。但是,加了static 的函數和變量就不用作為模板費類型參數了。(模板的非類型參數,必須是編譯期確定的,exterl 性質的,整形常量或者指針常量)
  2. 在C++中,我們希望同樣解決這種在不同的編譯unit中定義同名的函數和變量的,這樣就有了匿名的namespace, C++會為每個匿名的namespace生成一個唯一的 名字: __UNITQUE_NAMESPACE_NAME,並會再定義時后,加上 using namespace __UNITQUE_NAMESPACE_NAME,這樣也就就解決了變量和函數名字沖突問題。這里解決沖突的同時,並不會給函數和變量限定為 internal linkage。
  • 在闡述了上面的static 和 nick name namespace 后,
    • 需要備注第一點是,C++規定,字符常量默認是 internal 的,這個和全局函數和其他全局變量有點點不一樣。
    • 這里需要備注的第二點是:編譯單元,給函數和變量加上 static ,並不是說,頭文件中的函數和變量#include 到其他文件后,就不能使用了,這里的單元和文件作用域是不同的,編譯單元,可以理解為生成的一個obj 文件。內部鏈接指的是只能在一個obj文件中使用,外部鏈接指的是,可以跨obj使用。同一個obj內的函數和變量不管是什么鏈接性質,都必須名字惟一。引用其他obj的函數和變量,只需要在 使用前用 extern 聲明指定,在鏈接階段,連接器會去其他的obj中進行查找外部鏈接符號。

編譯單元:

當一個c或cpp文件在編譯時,預處理器首先遞歸包含頭文件,形成一個含有所有 必要信息的單個源文件,這個源文件就是一個編譯單元。這個編譯單元會被編譯成為一個與cpp 文件名同名的目標文件(.o或是.obj) 。連接程序把不同編譯單元中產生的符號聯系起來,構成一個可執行程序。

默認鏈接屬性:對於函數和變量,模認外部鏈接,對於const變量,默認內部鏈接。(可以通過添加extern和static改變鏈接屬性)

}

舉例如下:

linkage1.h

///////////////////////////////////////////////////////////

#pragma once

static char* pstatic = "static";               //內部鏈接

char const exNamei[] = "exNamei";               //內部鏈接

extern char const exName[] = "exName";          //外部鏈接,   所有的 *.obj 中要惟一

typedef void (*GFuncT)(void);

void GFunc(void)                                //外部鏈接,   所有的 *.obj 中要惟一

{

int i = 3 + 3;

return;

}

static void GFuncs(void)                         //內部鏈接

{

int i = 3 + 3;

return;

}

namespace

{

char const nickName[] = "nickName";      //內部鏈接,  會加上一個全局惟一的名稱空間(C++自動生成)

extern char const pnickNamespace[] = "nickNamespace";//外部鏈接,會加上一個全局惟一的名稱空間(C++自動生成)

void GFuncN(void)                    //外部鏈接,  會加上一個全局惟一的名稱空間(C++自動生成)

      {

int i = 3 + 3;

return;

      }

};

template<char const* name>

class TC

{

public:

protected:

private:

int i;

};

template<GFuncT func>

class TF

{

public:

void DoSomething()

      {

func();

      }

protected:

private:

//static const GFuncT = func;

};

linkage2.h

////////////////////////////////////////////////////////////////////

#pragma once

static char* pstatic = "static";               //內部鏈接, ok, 可以和 linkage1.h 中的變量同名,

char const exNamei[] = "exNamei";              //內部鏈接, ok,

// extern char const exName[] = "exName";      //外部鏈接,如果有這句,就會出現重定義錯誤

typedef void (*GFuncT)(void);

/*void GFunc(void)                             //外部鏈接,如果有這句,就會出現重定義錯誤

{

int i = 3 + 3;

return;

}*/

static void GFuncs(void)                       //內部鏈接 ok

{

int i = 3 + 3;

return;

}

namespace

{

char const nickName[] = "nickName";     //內部鏈接, ok

extern char const pnickNamespace[] = "nickNamespace";  //外部鏈接,ok, 因為有惟一名稱空間進行分割

void GFuncN(void)                        //外部鏈接,ok,  因為有惟一名稱空間進行分割

      {

int i = 3 + 3;

return;

      }

};

下面引用的文章綜合的詳述了編譯和鏈接 :

附件:(http://www.cppblog.com/shifan3/archive/2007/01/05/17325.html

     概述:


     有些人寫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變量的地址進行設計依賴。

  • 為什么類的靜態常量也不可以就地初始化:因為這相當於在頭文件里定義了const對象,相當於內部鏈接的變量,也就是每個包含類的單元都會出現一個相應的定義。作為例外,int/char等可以進行就地初始化,是因為這些變量可以直接被優化為立即數,就和宏一樣。

  • 內聯函數: C++里的內聯函數由於類似於一個宏,因此不存在鏈接屬性問題。

  • 為什么公共使用的內聯函數要定義於頭文件里:因為編譯時編譯單元之間互相不知道,如果內聯函數被定義於.cpp文件中,編譯其他使用該函數的編譯單元的時候沒有辦法找到函數的定義,因此無法對函數進行展開。所以說如果內聯函數定義於.cpp文件里,那么就只有這個cpp文件可以是用這個函數。

  • 頭文件里內聯函數被拒絕(編譯器,優化的時候拒絕對指定的函數執行內聯操作)會怎樣:如果定義於頭文件里的內聯函數被拒絕,那么編譯器會自動在每個包含了該頭文件的編譯單元里定義這個函數並且不導出符號。

  • 如果被拒絕的內聯函數里定義了靜態局部變量,這個變量會被定義於何處:早期的編譯器會在每個編譯單元里定義一個,並因此產生錯誤的結果,較新的編譯器會解決這個問題,手段未知。

  • 為什么export關鍵字沒人實現:export要求編譯器跨編譯單元查找函數定義,使得編譯器實現非常困難,相當於把內聯函數實現在CPP之內。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM