Ling Xu 的 C++ 技術隨筆

講一點和實現(xiàn)細節(jié)相關的東西。在Visual C++中，所有在main之前執(zhí)行的函數(shù)調(diào)用實際上都通過一個自動生成的函數(shù)來調(diào)用，比如下面這段代碼：

int func()
{
 return 1;
}

int data = func();

int main()
{
 return 0;
}

實際上生成了三個函數(shù)：

?func@@YAHXZ，對應于 func
_main 對應于 main
_$E1 對應于 data=func() 這句賦值語句。它調(diào)用了 func，并且完成賦值這個操作。

竅門在于，VC將 _$E1這個函數(shù)的指針放到了段CRT$XCU中：

CRT$XCU SEGMENT
_$S2 DD FLAT:_$E1
; Function compile flags: /Odt /RTCsu /ZI
CRT$XCU ENDS

這個段的定義為：

CRT$XCU SEGMENT DWORD USE32 PUBLIC 'DATA'
CRT$XCU ENDS

參考 crt0dat.c 文件可以看到：

extern _CRTALLOC(".CRT$XIA") _PIFV __xi_a[];
extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[];    /* C initializers */
extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[];    /* C++ initializers */
extern _CRTALLOC(".CRT$XPA") _PVFV __xp_a[];
extern _CRTALLOC(".CRT$XPZ") _PVFV __xp_z[];    /* C pre-terminators */
extern _CRTALLOC(".CRT$XTA") _PVFV __xt_a[];
extern _CRTALLOC(".CRT$XTZ") _PVFV __xt_z[];    /* C terminators */

這里實際上有一個很巧妙的地方在于，VC應用了x86上段是連續(xù)并且可重疊的概念，因此CRT$XCU是位于CRT$XCA到CRT$XCZ之間，具體說，段的順序是：

CRT$XCA SEGMENT DWORD USE32 PUBLIC 'DATA'
CRT$XCA ENDS
CRT$XCU SEGMENT DWORD USE32 PUBLIC 'DATA'
CRT$XCU ENDS
CRT$XCL SEGMENT DWORD USE32 PUBLIC 'DATA'
CRT$XCL ENDS
CRT$XCC SEGMENT DWORD USE32 PUBLIC 'DATA'
CRT$XCC ENDS
CRT$XCZ SEGMENT DWORD USE32 PUBLIC 'DATA'
CRT$XCZ ENDS

由于CRT$XCA開始都是C++初始化函數(shù)，_PVFV實際上就是 void (*_PVFV)()，因此CRT的_initterm()函數(shù)就把這個段中的數(shù)據(jù)作為一個函數(shù)指針數(shù)組來訪問，依次調(diào)用其中的函數(shù)，從而完成系統(tǒng)所有初始化操作。

最后，也是最關鍵的問題，就是實際上每個 CPP 文件編譯好以后都有初始化函數(shù)，并且其指針位于 CRT$XC? 段中，隨后連接程序 LINK 做了最后一個重要的任務，就是把所有具有相同名字的段合并成為一個單獨的段（這也就是連接程序名字的由來之一），合并的做法就是簡單地把每個段中的數(shù)據(jù)按順序前后放到一個連續(xù)的空間就可以了。這樣在最終運行的時候，程序看到的CRT$XC?段也就是一個連續(xù)的數(shù)組，而不是多個數(shù)組。

至于順序問題，在這里就可以看到，是由連接程序最后做拼接時候確定的。連接程序拼接的順序，基本上是它看到OBJ文件的順序，也就是在連接程序命令行指定的順序。因此，在程序中決不能依賴于這個順序，因為在連接程序命令行中的文件順序是不確定的。

以上是初始化程序的順序，至于析構函數(shù)（或者在main函數(shù)之后的函數(shù)調(diào)用）則是通過用at_exit函數(shù)注冊的順序來確定，而注冊往往是在初始化的時候進行，因此析構函數(shù)的調(diào)用順序也是不確定的。