以下代碼在VC6.0中并不會(huì)拋出異常
try
{
??
int
?
*
?p?
=
?
new
?
int
[
/*
0xFFFFFFE0
*/
numeric_limits
<
int
>
::max()];
?}
?
catch
(bad_alloc?x){
??cerr
<<
x.what();
?}
和標(biāo)準(zhǔn)C++描述的不一樣.
new會(huì)被鏈接到一個(gè)debug版本的庫(kù),然后跳出一個(gè)assert.
就算參數(shù)符合assert條件,若分配失敗,只是返回0,并不拋出bac_alloc異常.
在網(wǎng)上找了兩篇文章,對(duì)VC甚不耐煩
(據(jù)說(shuō)出自CSDN,誰(shuí)寫的無(wú)心情去考究了):
在VC6.0中如何讓new操作失敗后拋出異常？
標(biāo)準(zhǔn)C++規(guī)定new一個(gè)對(duì)象時(shí)如果分配內(nèi)存失敗就應(yīng)拋出一個(gè)std::bad_alloc異常，如果不希望拋出異常而僅僅傳回一個(gè)NULL指針，可以用new的無(wú)異常版本：new(nothrow)。
VC6.0在<new>頭文件中聲明了這兩種operator new操作符：
void *__cdecl operator new(size_t) _THROW1(std::bad_alloc)；
void *__cdecl operator new(size_t, const std::nothrow_t&) _THROW0()；
并分別定義在newop.cpp和newop2.cpp中。而_THROW0和_THROW1則是兩個(gè)宏，在Include目錄的xstddef文件中定義:
#define _THROW0() throw ()
#define _THROW1(x) throw (x)
newop.cpp和newop2.cpp對(duì)應(yīng)的目標(biāo)模塊被打包進(jìn)標(biāo)準(zhǔn)C++庫(kù)中。標(biāo)準(zhǔn)C++庫(kù)有若干個(gè)版本: libcp.lib(單線程靜態(tài)版)、libcpd.lib(單線程靜態(tài)調(diào)試版)、libcpmt.lib(多線程靜態(tài)版)、libcpmtd.lib(多線程靜態(tài)調(diào)試版)、msvcprt.lib(多線程動(dòng)態(tài)版的導(dǎo)入庫(kù))，msvcprtd.lib(多線程動(dòng)態(tài)調(diào)試版的導(dǎo)入庫(kù))，這些庫(kù)與相應(yīng)版本的C標(biāo)準(zhǔn)庫(kù)一起使用，比如libcp.lib與libc.lib搭配。另外，VC6.0在new.cpp還定義了一個(gè)operator new，原型如下 :
void * operator new( unsigned int cb )
而new.cpp對(duì)應(yīng)的目標(biāo)模塊卻是被打包進(jìn)C標(biāo)準(zhǔn)庫(kù)中的(是不是有點(diǎn)奇怪?)。
一般來(lái)說(shuō)，程序員不會(huì)顯式指定鏈接C++標(biāo)準(zhǔn)庫(kù)，可是當(dāng)程序中確實(shí)使用了標(biāo)準(zhǔn)C++庫(kù)時(shí)鏈接器卻能聰明地把相應(yīng)的C++標(biāo)準(zhǔn)庫(kù)文件加進(jìn)輸入文件列表，這是為什么？其實(shí)任何一個(gè)C++標(biāo)準(zhǔn)頭文件都會(huì)直接或間接地包含use_ansi.h文件，打開它一看便什么都清楚了(源碼之前，了無(wú)秘密) :
/***
*use_ansi.h - pragmas for ANSI Standard C++ libraries
*
* Copyright (c) 1996-1997, Microsoft Corporation. All rights reserved.
*
*Purpose:
* This header is intended to force the use of the appropriate ANSI
* Standard C++ libraries whenever it is included.
*
* [Public]
*
****/
#if _MSC_VER > 1000
#pragma once
#endif
#ifndef _USE_ANSI_CPP
#define _USE_ANSI_CPP
#ifdef _MT
#ifdef _DLL
#ifdef _DEBUG
#pragma comment(lib,"msvcprtd")
#else// _DEBUG
#pragma comment(lib,"msvcprt")
#endif// _DEBUG
#else// _DLL
#ifdef _DEBUG
#pragma comment(lib,"libcpmtd")
#else// _DEBUG
#pragma comment(lib,"libcpmt")
#endif// _DEBUG
#endif// _DLL
#else// _MT
#ifdef _DEBUG
#pragma comment(lib,"libcpd")
#else// _DEBUG
#pragma comment(lib,"libcp")
#endif// _DEBUG
#endif
#endif// _USE_ANSI_CPP
現(xiàn)在我們用實(shí)際代碼來(lái)測(cè)試一下new會(huì)不會(huì)拋出異常，建一個(gè)test.cpp源文件：
// test.cpp
#include <new>
#include <iostream>
using namespace std;
class BigClass
{
public:
BigClass() {}
~BigClass(){}
char BigArray[0x7FFFFFFF];
};
int main()
{
try
{
BigClass *p = new BigClass;
}
catch( bad_alloc &a)
{
cout << "new BigClass, threw a bad_alloc exception" << endl;
}
BigClass *q = new(nothrow) BigClass;
if ( q == NULL )
cout << "new(nothrow) BigClass, returned a NULL pointer" << endl;
try
{
BigClass *r = new BigClass[1];
}
catch( bad_alloc &a)
{
cout << "new BigClass[1], threw a bad_alloc exception" << endl;
}
return 0;
}
根據(jù)VC6.0編譯器與鏈接器的做法(請(qǐng)參考《為什么會(huì)出現(xiàn)LNK2005"符號(hào)已定義"的鏈接錯(cuò)誤？》)，鏈接器會(huì)首先在C++標(biāo)準(zhǔn)庫(kù)中解析符號(hào)，然后才是C標(biāo)準(zhǔn)庫(kù)，所以如果開發(fā)者沒有自定義operator new的話最后程序鏈接的應(yīng)該是C++標(biāo)準(zhǔn)庫(kù)中newop.obj和newop2.obj模塊里的代碼。可是程序運(yùn)行的結(jié)果卻是:
new(nothrow) BigClass, returned a NULL pointer
顯然程序始終未拋出bad_alloc異常。單步跟蹤觀察，發(fā)現(xiàn)第1個(gè)和第3個(gè)new實(shí)際上調(diào)用了new.cpp里的operator new，而第二個(gè)new(nothrow)則正確地調(diào)用了newop2.cpp定義的版本。很難理解是吧？但是當(dāng)你用
dumpbin /SYMBOLS libcp.lib
dump出libcp.lib所有的符號(hào)信息時(shí)，你會(huì)發(fā)現(xiàn)其中的newop.obj模塊沒有定義任何符號(hào)(其它版本也一樣)。不可思議！newop.cpp的實(shí)現(xiàn)代碼明明寫在那兒，怎么會(huì)....？讓我們?cè)僮屑?xì)看看newop.cpp，咦，operator new的定義被包裹在一個(gè)#if...#endif塊中:
#if !defined(_MSC_EXTENSIONS)
...
...
void *__cdecl operator new(size_t size) _THROW1(_STD bad_alloc)
{
...
...
}
#endif
哦，原來(lái)需要_MSC_EXTENSIONS宏未定義，實(shí)現(xiàn)代碼才是有效的啊。那么這個(gè)宏是什么意思？其實(shí)Visual C++在語(yǔ)言層面上對(duì)ANSI C標(biāo)準(zhǔn)做了一些特殊的擴(kuò)展，定義_MSC_EXTENSIONS意味著編譯器支持這樣的擴(kuò)展，沒有定義它編譯器就會(huì)嚴(yán)格按照ANSI C標(biāo)準(zhǔn)來(lái)編譯程序。實(shí)際上如果指定了編譯選項(xiàng)/Ze編譯器就會(huì)自動(dòng)定義這個(gè)宏，指定/Za則不會(huì)，而且/Ze是缺省選項(xiàng)。作者猜想Visual Studio的開發(fā)人員在build標(biāo)準(zhǔn)C++庫(kù)時(shí)很可能沒有指定/Za，導(dǎo)致newop.cpp中的operator new定義被無(wú)情拋棄。是他們的疏漏嗎？我看未必，大家可以試試用/Za選項(xiàng)去編譯那些標(biāo)準(zhǔn)庫(kù)文件，看看有多少編譯不通過(guò)。VC標(biāo)準(zhǔn)庫(kù)的實(shí)現(xiàn)用了很多微軟擴(kuò)展的語(yǔ)言特性，不指定/Za是情有可原的，我不明白的是newop.cpp的作者(好象是P.J. Plauger老人家)為什么會(huì)加上一個(gè)如此愚蠢的"#if !defined(_MSC_EXTENSIONS)"，因?yàn)閷?shí)在看不出這個(gè)operator new定義與_MSC_EXTENSIONS有什么沖突的地方。
既然標(biāo)準(zhǔn)C++庫(kù)里的newop.obj是個(gè)空殼，那我們就只好自己動(dòng)手豐衣足食了。把newop.cpp和dbgint.h(都在VC98\crt\src目錄下)拷貝到test.cpp所在的目錄，并將newop.cpp中的
#include <dbgint.h>
改成
#include "dbgint.h"
然后用
cl /c /Za /D_CRTBLD newop.cpp
編譯它。/D_CRTBLD定義了_CRTBLD宏，為什么這么做呢？因?yàn)閐bgint.h屬于內(nèi)部頭文件，VC不希望應(yīng)用程序用到它，便在文件中埋伏了這么一段:
#ifndef _CRTBLD
/*
* This is an internal C runtime header file. It is used when building
* the C runtimes only. It is not to be used as a public header file.
*/
#error ERROR: Use of C runtime library internal header file.
#endif /* _CRTBLD */
可我們確確實(shí)實(shí)是想build標(biāo)準(zhǔn)庫(kù)(的一部分)，所以只好強(qiáng)行突破這個(gè)限制了。然后編譯test.cpp:
cl /c /GX test.cpp
最后進(jìn)行鏈接:
link test.obj newop.obj
這時(shí)再運(yùn)行test.exe輸出的結(jié)果就是
new BigClass, threw a bad_alloc exception
new(nothrow) BigClass, returned a NULL pointer
new BigClass[1], threw a bad_alloc exception
值得慶幸的是雖然VC6.0如此弱智，但VC7.1卻表現(xiàn)良好，原因是VC7.1的newop.cpp和newaop.cpp(數(shù)組版)取消了那個(gè)愚的"#if !defined(_MSC_EXTENSIONS)"，于是標(biāo)準(zhǔn)C++庫(kù)中的newop.obj和newaop.obj模塊都實(shí)實(shí)在在地有了相應(yīng)代碼。另外，nothrow版的定義也分別轉(zhuǎn)移到了newopnt.cpp和newaopnt.cpp中。
后記: 作者在2001年便碰到過(guò)這個(gè)問(wèn)題，百思不得其解，于是在CSDN論壇上發(fā)問(wèn)，也不見答復(fù)。從此便擱置一旁，直到最近因探究LNK2005鏈接錯(cuò)誤而徹底弄清楚VC鏈接器解析符號(hào)的規(guī)則后，才意識(shí)到二者或有聯(lián)系。于是重拾舊疑，順藤而上，果然問(wèn)題就迎刃而解。此題雖小，功夫卻做足，最后總算水落石出，解除了4年的積惑。
另一篇文章(網(wǎng)上被大量轉(zhuǎn)載,來(lái)源不可知,我覺得這篇文章有些內(nèi)容不一定正確):
為什么會(huì)出現(xiàn)LNK2005"符號(hào)已定義"的鏈接錯(cuò)誤?
? 許多Visual C++的使用者都碰到過(guò)LNK2005:symbol already defined和LNK1169:one or more multiply defined symbols found這樣的鏈接錯(cuò)誤，而且通常是在使用第三方庫(kù)時(shí)遇到的。對(duì)于這個(gè)問(wèn)題，有的朋友可能不知其然，而有的朋友可能知其然卻不知其所以然，那么本文就試圖為大家徹底解開關(guān)于它的種種疑惑。
??? 大家都知道，從C/C++源程序到可執(zhí)行文件要經(jīng)歷兩個(gè)階段:(1)編譯器將源文件編譯成匯編代碼，然后由匯編器(assembler)翻譯成機(jī)器指令(再加上其它相關(guān)信息)后輸出到一個(gè)個(gè)目標(biāo)文件(object file,VC的編譯器編譯出的目標(biāo)文件默認(rèn)的后綴名是.obj)中；(2)鏈接器(linker)將一個(gè)個(gè)的目標(biāo)文件(或許還會(huì)有若干程序庫(kù))鏈接在一起生成一個(gè)完整的可執(zhí)行文件。
??? 編譯器編譯源文件時(shí)會(huì)把源文件的全局符號(hào)(global symbol)分成強(qiáng)(strong)和弱(weak)兩類傳給匯編器，而隨后匯編器則將強(qiáng)弱信息編碼并保存在目標(biāo)文件的符號(hào)表中。那么何謂強(qiáng)弱呢？編譯器認(rèn)為函數(shù)與初始化了的全局變量都是強(qiáng)符號(hào)，而未初始化的全局變量則成了弱符號(hào)。比如有這么個(gè)源文件:
extern int errorno;
int buf[2] = {1,2};
int *p;
int main()
{
?? return 0;
}
其中main、buf是強(qiáng)符號(hào)，p是弱符號(hào)，而errorno則非強(qiáng)非弱，因?yàn)樗皇莻€(gè)外部變量的使用聲明。
??? 有了強(qiáng)弱符號(hào)的概念，我們就可以看看鏈接器是如何處理與選擇被多次定義過(guò)的全局符號(hào):
規(guī)則1: 不允許強(qiáng)符號(hào)被多次定義(即不同的目標(biāo)文件中不能有同名的強(qiáng)符號(hào))；
規(guī)則2: 如果一個(gè)符號(hào)在某個(gè)目標(biāo)文件中是強(qiáng)符號(hào)，在其它文件中都是弱符號(hào)，那么選擇強(qiáng)符號(hào)；
規(guī)則3: 如果一個(gè)符號(hào)在所有目標(biāo)文件中都是弱符號(hào)，那么選擇其中任意一個(gè)；
??? 由上可知多個(gè)目標(biāo)文件不能重復(fù)定義同名的函數(shù)與初始化了的全局變量，否則必然導(dǎo)致LNK2005和LNK1169兩種鏈接錯(cuò)誤?？墒?，有的時(shí)候我們并沒有在自己的程序中發(fā)現(xiàn)這樣的重定義現(xiàn)象，卻也遇到了此種鏈接錯(cuò)誤，這又是何解？嗯，問(wèn)題稍微有點(diǎn)兒復(fù)雜，容我慢慢道來(lái)。
??? 眾所周知，ANSI C/C++ 定義了相當(dāng)多的標(biāo)準(zhǔn)函數(shù)，而它們又分布在許多不同的目標(biāo)文件中，如果直接以目標(biāo)文件的形式提供給程序員使用的話，就需要他們確切地知道哪個(gè)函數(shù)存在于哪個(gè)目標(biāo)文件中，并且在鏈接時(shí)顯式地指定目標(biāo)文件名才能成功地生成可執(zhí)行文件，顯然這是一個(gè)巨大的負(fù)擔(dān)。所以C語(yǔ)言提供了一種將多個(gè)目標(biāo)文件打包成一個(gè)文件的機(jī)制，這就是靜態(tài)程序庫(kù)(static library)。開發(fā)者在鏈接時(shí)只需指定程序庫(kù)的文件名，鏈接器就會(huì)自動(dòng)到程序庫(kù)中尋找那些應(yīng)用程序確實(shí)用到的目標(biāo)模塊，并把(且只把)它們從庫(kù)中拷貝出來(lái)參與構(gòu)建可執(zhí)行文件。幾乎所有的C/C++開發(fā)系統(tǒng)都會(huì)把標(biāo)準(zhǔn)函數(shù)打包成標(biāo)準(zhǔn)庫(kù)提供給開發(fā)者使用(有不這么做的嗎？)。
??? 程序庫(kù)為開發(fā)者帶來(lái)了方便，但同時(shí)也是某些混亂的根源。我們來(lái)看看鏈接器是如何解析(resolve)對(duì)程序庫(kù)的引用的。
???
??? 在符號(hào)解析(symbol resolution)階段，鏈接器按照所有目標(biāo)文件和庫(kù)文件出現(xiàn)在命令行中的順序從左至右依次掃描它們，在此期間它要維護(hù)若干個(gè)集合:(1)集合E是將被合并到一起組成可執(zhí)行文件的所有目標(biāo)文件集合；(2)集合U是未解析符號(hào)(unresolved symbols，比如已經(jīng)被引用但是還未被定義的符號(hào))的集合；(3)集合D是所有之前已被加入到E的目標(biāo)文件定義的符號(hào)集合。一開始，E、U、D都是空的。
(1): 對(duì)命令行中的每一個(gè)輸入文件f，鏈接器確定它是目標(biāo)文件還是庫(kù)文件，如果它是目標(biāo)文件，就把f加入到E，并把f中未解析的符號(hào)和已定義的符號(hào)分別加入到U、D集合中，然后處理下一個(gè)輸入文件。
(2): 如果f是一個(gè)庫(kù)文件，鏈接器會(huì)嘗試把U中的所有未解析符號(hào)與f中各目標(biāo)模塊定義的符號(hào)進(jìn)行匹配。如果某個(gè)目標(biāo)模塊m定義了一個(gè)U中的未解析符號(hào)，那么就把m加入到E中，并把m中未解析的符號(hào)和已定義的符號(hào)分別加入到U、D集合中。不斷地對(duì)f中的所有目標(biāo)模塊重復(fù)這個(gè)過(guò)程直至到達(dá)一個(gè)不動(dòng)點(diǎn)(fixed point)，此時(shí)U和D不再變化。而那些未加入到E中的f里的目標(biāo)模塊就被簡(jiǎn)單地丟棄，鏈接器繼續(xù)處理下一輸入文件。
(3): 如果處理過(guò)程中往D加入一個(gè)已存在的符號(hào)，或者當(dāng)掃描完所有輸入文件時(shí)U非空，鏈接器報(bào)錯(cuò)并停止動(dòng)作。否則，它把E中的所有目標(biāo)文件合并在一起生成可執(zhí)行文件。
??? VC帶的編譯器名字叫cl.exe，它有這么幾個(gè)與標(biāo)準(zhǔn)程序庫(kù)有關(guān)的選項(xiàng): /ML、/MLd、/MT、/MTd、/MD、/MDd。這些選項(xiàng)告訴編譯器應(yīng)用程序想使用什么版本的C標(biāo)準(zhǔn)程序庫(kù)。/ML(缺省選項(xiàng))對(duì)應(yīng)單線程靜態(tài)版的標(biāo)準(zhǔn)程序庫(kù)(libc.lib)；/MT對(duì)應(yīng)多線程靜態(tài)版標(biāo)準(zhǔn)庫(kù)(libcmt.lib)，此時(shí)編譯器會(huì)自動(dòng)定義_MT宏；/MD對(duì)應(yīng)多線程DLL版(導(dǎo)入庫(kù)msvcrt.lib，DLL是msvcrt.dll)，編譯器自動(dòng)定義_MT和_DLL兩個(gè)宏。后面加d的選項(xiàng)都會(huì)讓編譯器自動(dòng)多定義一個(gè)_DEBUG宏，表示要使用對(duì)應(yīng)標(biāo)準(zhǔn)庫(kù)的調(diào)試版，因此/MLd對(duì)應(yīng)調(diào)試版單線程靜態(tài)標(biāo)準(zhǔn)庫(kù)(libcd.lib)，/MTd對(duì)應(yīng)調(diào)試版多線程靜態(tài)標(biāo)準(zhǔn)庫(kù)(libcmtd.lib)，/MDd對(duì)應(yīng)調(diào)試版多線程DLL標(biāo)準(zhǔn)庫(kù)(導(dǎo)入庫(kù)msvcrtd.lib，DLL是msvcrtd.dll)。雖然我們的確在編譯時(shí)明白無(wú)誤地告訴了編譯器應(yīng)用程序希望使用什么版本的標(biāo)準(zhǔn)庫(kù)，可是當(dāng)編譯器干完了活，輪到鏈接器開工時(shí)它又如何得知一個(gè)個(gè)目標(biāo)文件到底在思念誰(shuí)？為了傳遞相思，我們的編譯器就干了點(diǎn)秘密的勾當(dāng)。在cl編譯出的目標(biāo)文件中會(huì)有一個(gè)專門的區(qū)域(關(guān)心這個(gè)區(qū)域到底在文件中什么地方的朋友可以參考COFF和PE文件格式)存放一些指導(dǎo)鏈接器如何工作的信息，其中有一種就叫缺省庫(kù)(default library)，這些信息指定了一個(gè)或多個(gè)庫(kù)文件名，告訴鏈接器在掃描的時(shí)候也把它們加入到輸入文件列表中(當(dāng)然順序位于在命令行中被指定的輸入文件之后)。說(shuō)到這里，我們先來(lái)做個(gè)小實(shí)驗(yàn)。寫個(gè)頂頂簡(jiǎn)單的程序，然后保存為main.c :
/* main.c */
int main() { return 0; }
用下面這個(gè)命令編譯main.c(什么？你從不用命令行來(lái)編譯程序？這個(gè)......) :
cl /c main.c
/c是告訴cl只編譯源文件，不用鏈接。因?yàn)?ML是缺省選項(xiàng)，所以上述命令也相當(dāng)于: cl /c /ML main.c 。如果沒什么問(wèn)題的話(要出了問(wèn)題才是活見鬼！當(dāng)然除非你的環(huán)境變量沒有設(shè)置好，這時(shí)你應(yīng)該去VC的bin目錄下找到vcvars32.bat文件然后運(yùn)行它。)，當(dāng)前目錄下會(huì)出現(xiàn)一個(gè)main.obj文件，這就是我們可愛的目標(biāo)文件。隨便用一個(gè)文本編輯器打開它(是的，文本編輯器，大膽地去做別害怕)，搜索"defaultlib"字符串，通常你就會(huì)看到這樣的東西: "-defaultlib:LIBC -defaultlib:OLDNAMES"。啊哈，沒錯(cuò)，這就
是保存在目標(biāo)文件中的缺省庫(kù)信息。我們的目標(biāo)文件顯然指定了兩個(gè)缺省庫(kù)，一個(gè)是單線程靜態(tài)版標(biāo)準(zhǔn)庫(kù)libc.lib(這與/ML選項(xiàng)相符)，另外一個(gè)是oldnames.lib(它是為了兼容微軟以前的C/C++開發(fā)系統(tǒng))。
??? VC的鏈接器是link.exe，因?yàn)閙ain.obj保存了缺省庫(kù)信息，所以可以用
link main.obj libc.lib
或者
link main.obj
來(lái)生成可執(zhí)行文件main.exe，這兩個(gè)命令是等價(jià)的。但是如果你用
link main.obj libcd.lib
的話，鏈接器會(huì)給出一個(gè)警告: "warning LNK4098: defaultlib "LIBC" conflicts with use of other libs; use /NODEFAULTLIB:library"，因?yàn)槟泔@式指定的標(biāo)準(zhǔn)庫(kù)版本與目標(biāo)文件的缺省值不一致。通常來(lái)說(shuō)，應(yīng)該保證鏈接器合并的所有目標(biāo)文件指定的缺省標(biāo)準(zhǔn)庫(kù)版本一致，否則編譯器一定會(huì)給出上面的警告，而LNK2005和LNK1169鏈接錯(cuò)誤則有時(shí)會(huì)出現(xiàn)有時(shí)不會(huì)。那么這個(gè)有時(shí)到底是什么時(shí)候？呵呵，別著急，下面的一切正是為喜歡追根究底的你準(zhǔn)備的。
??? 建一個(gè)源文件，就叫mylib.c，內(nèi)容如下:
/* mylib.c */
#include <stdio.h>
void foo()
{
?? printf("%s","I am from mylib!\n");
}
用
cl /c /MLd mylib.c
命令編譯，注意/MLd選項(xiàng)是指定libcd.lib為默認(rèn)標(biāo)準(zhǔn)庫(kù)。lib.exe是VC自帶的用于將目標(biāo)文件打包成程序庫(kù)的命令，所以我們可以用
lib /OUT:my.lib mylib.obj
將mylib.obj打包成庫(kù)，輸出的庫(kù)文件名是my.lib。接下來(lái)把main.c改成:
/* main.c */
void foo();
int main()
{
?? foo();
?? return 0;
}
用
cl /c main.c
編譯，然后用
link main.obj my.lib
進(jìn)行鏈接。這個(gè)命令能夠成功地生成main.exe而不會(huì)產(chǎn)生LNK2005和LNK1169鏈接錯(cuò)誤，你僅僅是得到了一條警告信息:"warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs; use /NODEFAULTLIB:library"。我們根據(jù)前文所述的掃描規(guī)則來(lái)分析一下鏈接器此時(shí)做了些啥。
??? 一開始E、U、D都是空集，鏈接器首先掃描到main.obj，把它加入E集合，同時(shí)把未解析的foo加入U(xiǎn)，把main加入D，而且因?yàn)閙ain.obj的默認(rèn)標(biāo)準(zhǔn)庫(kù)是libc.lib，所以它被加入到當(dāng)前輸入文件列表的末尾。接著掃描my.lib，因?yàn)檫@是個(gè)庫(kù)，所以會(huì)拿當(dāng)前U中的所有符號(hào)(當(dāng)然現(xiàn)在就一個(gè)foo)與my.lib中的所有目標(biāo)模塊(當(dāng)然也只有一個(gè)mylib.obj)依次匹配，看是否有模塊定義了U中的符號(hào)。結(jié)果mylib.obj確實(shí)定義了foo，于是它被加入到E，foo從U轉(zhuǎn)移到D，mylib.obj引用的printf加入到U，同樣地，mylib.obj指定的默認(rèn)標(biāo)準(zhǔn)庫(kù)是libcd.lib，它也被加到當(dāng)前輸入文件列表的末尾(在libc.lib的后面)。不斷地在my.lib庫(kù)的各模塊上進(jìn)行迭代以匹配U中的符號(hào)，直到U、D都不再變化。很明顯，現(xiàn)在就已經(jīng)到達(dá)了這么一個(gè)不動(dòng)點(diǎn)，所以接著掃描下一個(gè)輸入文件，就是libc.lib。鏈接器發(fā)現(xiàn)libc.lib里的printf.obj里定義有printf，于是printf從U移到D，而printf.obj被加入到E，它定義的所有符號(hào)加入到D，它里頭的未解析符號(hào)加入到U。鏈接器還會(huì)把每個(gè)程序都要用到的一些初始化操作所在的目標(biāo)模塊(比如crt0.obj等)及它們所引用的模塊(比如malloc.obj、free.obj等)自動(dòng)加入到E中，并更新U和D以反應(yīng)這個(gè)變化。事實(shí)上，標(biāo)準(zhǔn)庫(kù)各目標(biāo)模塊里的未解析符號(hào)都可以在庫(kù)內(nèi)其它模塊中找到定義，因此當(dāng)鏈接器處理完libc.lib時(shí)，U一定是空的。最后處理libcd.lib，因?yàn)榇藭r(shí)U已經(jīng)為空，所以鏈接器會(huì)拋棄它里面的所有目標(biāo)模塊從而結(jié)束掃描，然后合并E中的目標(biāo)模塊并輸出可執(zhí)行文件。
??? 上文描述了雖然各目標(biāo)模塊指定了不同版本的缺省標(biāo)準(zhǔn)庫(kù)但仍然鏈接成功的例子，接下來(lái)你將目睹因?yàn)檫@種不嚴(yán)謹(jǐn)而導(dǎo)致的悲慘失敗。
??? 修改mylib.c成這個(gè)樣子:
#include <crtdbg.h>
void foo()
{
?? // just a test , don't care memory leak
?? _malloc_dbg( 1, _NORMAL_BLOCK, __FILE__, __LINE__ );
}
其中_malloc_dbg不是ANSI C的標(biāo)準(zhǔn)庫(kù)函數(shù)，它是VC標(biāo)準(zhǔn)庫(kù)提供的malloc的調(diào)試版，與相關(guān)函數(shù)配套能幫助開發(fā)者抓各種內(nèi)存錯(cuò)誤。使用它一定要定義_DEBUG宏，否則預(yù)處理器會(huì)把它自動(dòng)轉(zhuǎn)為malloc。繼續(xù)用
cl /c /MLd mylib.c
lib /OUT:my.lib mylib.obj
編譯打包。當(dāng)再次用
link main.obj my.lib
進(jìn)行鏈接時(shí)，我們看到了什么？天哪，一堆的LNK2005加上個(gè)貴為"fatal error"的LNK1169墊底，當(dāng)然還少不了那個(gè)LNK4098。鏈接器是不是瘋了？不，你冤枉可憐的鏈接器了，我拍胸脯保證它可是一直在盡心盡責(zé)地照章辦事。
??? 一開始E、U、D為空，鏈接器掃描main.obj，把它加入E，把foo加入U(xiǎn)，把main加入D，把libc.lib加入到當(dāng)前輸入文件列表的末尾。接著掃描my.lib，foo從U轉(zhuǎn)移到D，_malloc_dbg加入到U，libcd.lib加到當(dāng)前輸入文件列表的尾部。然后掃描libc.lib，這時(shí)會(huì)發(fā)現(xiàn)libc.lib里任何一個(gè)目標(biāo)模塊都沒有定義_malloc_dbg(它只在調(diào)試版的標(biāo)準(zhǔn)庫(kù)中存在)，所以不會(huì)有任何一個(gè)模塊因?yàn)開malloc_dbg而加入E，但是每個(gè)程序都要用到的初始化模塊(如crt0.obj等)及它們所引用的模塊(比如malloc.obj、free.obj等)還是會(huì)自動(dòng)加入到E中，同時(shí)U和D被更新以反應(yīng)這個(gè)變化。當(dāng)鏈接器處理完libc.lib時(shí)，U只剩_malloc_dbg這一個(gè)符號(hào)。最后處理libcd.lib，發(fā)現(xiàn)dbgheap.obj定義了_malloc_dbg，于是dbgheap.obj加入到E，它里頭的未解析符號(hào)加入U(xiǎn)，它定義的所有其它符號(hào)也加入D，這時(shí)災(zāi)難便來(lái)了。之前malloc等符號(hào)已經(jīng)在D中(隨著libc.lib里的malloc.obj加入E而加入的)，而dbgheap.obj又定義了包括malloc在內(nèi)的許多同名符號(hào)，這引發(fā)了重定義沖突，鏈接器只好中斷工作并報(bào)告錯(cuò)誤。
??? 現(xiàn)在我們?cè)撝溃溄悠魍耆珱]有責(zé)任，責(zé)任在我們自己的身上。是我們粗心地把缺省標(biāo)準(zhǔn)庫(kù)版本不一致的目標(biāo)文件(main.obj)與程序庫(kù)(my.lib)鏈接起來(lái)，導(dǎo)致了大災(zāi)難。解決辦法很簡(jiǎn)單，要么用/MLd選項(xiàng)來(lái)重編譯main.c；要么用/ML選項(xiàng)重編譯mylib.c。
??? 在上述例子中，我們擁有庫(kù)my.lib的源代碼(mylib.c)，所以可以用不同的選項(xiàng)重新編譯這些源代碼并再次打包?？扇绻褂玫氖堑谌降膸?kù)，它并沒有提供源代碼，那么我們就只有改變自己程序的編譯選項(xiàng)來(lái)適應(yīng)這些庫(kù)了。但是如何知道庫(kù)中目標(biāo)模塊指定的默認(rèn)庫(kù)呢？其實(shí)VC提供的一個(gè)小工具便可以完成任務(wù)，這就是dumpbin.exe。運(yùn)行下面這個(gè)命令
dumpbin /DIRECTIVES my.lib
然后在輸出中找那些"Linker Directives"引導(dǎo)的信息，你一定會(huì)發(fā)現(xiàn)每一處這樣的信息都會(huì)包含若干個(gè)類似"-defaultlib:XXXX"這樣的字符串，其中XXXX便代表目標(biāo)模塊指定的缺省庫(kù)名。
??? 知道了第三方庫(kù)指定的默認(rèn)標(biāo)準(zhǔn)庫(kù)，再用合適的選項(xiàng)編譯我們的應(yīng)用程序，就可以避免LNK2005和LNK1169鏈接錯(cuò)誤。喜歡IDE的朋友，你一樣可以到 "Project屬性" -> "C/C++" -> "代碼生成(code generation)" -> "運(yùn)行時(shí)庫(kù)(run-time library)" 項(xiàng)下設(shè)置應(yīng)用程序的默認(rèn)標(biāo)準(zhǔn)庫(kù)版本，這與命令行選項(xiàng)的效果是一樣的。
好文章還不是一般的多:
Under The Hood, July 1997
http://comcamp.diy.myrice.com/techarticles/vc/0010.htm
為什么全局變量沒有初始化?
http://comcamp.diy.myrice.com/techarticles/vc/0011.htm
鏈接一個(gè)靜態(tài)LIB,不在客戶端代碼中使用它的任何變量和代碼,但要讓這個(gè)LIB的全局變量被初始化的方法是:
這個(gè)鏈接庫(kù)頭文件應(yīng)該這么寫:
extern CMyClass *g_pObject ;
static void *__dummy = (void*)g_pObject ;
// lib.cpp
CMyClass *g_pObject = CMyClass::Instance() ; // Singleton
__dummy會(huì)出現(xiàn)在任何包含這個(gè)頭文件的CPP文件的OBJ中,所以LINKER會(huì)把靜態(tài)庫(kù)中的g_pObject鏈接到Exe中,包括它的構(gòu)造和析構(gòu)
<iostream>很有意思,其中有一行
static ios_base::Init _Ios_init;
ios_base::Init是個(gè)類,在類的構(gòu)造中判斷構(gòu)造是否第一次被調(diào)用,如果是,則初始化cout,cin,cerr等
在類的析構(gòu)中判斷這是不是最后一次構(gòu)造,如果是,則調(diào)用cout.flush() .... (basic_ostream等的析構(gòu)并沒有調(diào)用flush)
具體怎么判斷是否第一次調(diào)用構(gòu)造,是否最后一次調(diào)用析構(gòu),那是用一個(gè)int的靜態(tài)類成員來(lái)計(jì)算...
其實(shí)這樣會(huì)增加exe文件的尺寸,降低程序啟動(dòng)速度....