以下代码在VC6.0中并不会抛出异常
try
{
int
*
p
=
new
int
[
/*
0xFFFFFFE0
*/
numeric_limits
<
int
>
::max()];
}
catch
(bad_alloc x){
cerr
<<
x.what();
}
和标准C++描述的不一样.
new会被链接到一个debug版本的库,然后跳出一个assert.
就算参数符合assert条件,若分配失败,只是返回0,并不抛出bac_alloc异常.
在网上找了两篇文章,对VC甚不耐烦
(据说出自CSDN,谁写的无心情去考究了):
在VC6.0中如何让new操作失败后抛出异常？
标准C++规定new一个对象时如果分配内存失败就应抛出一个std::bad_alloc异常，如果不希望抛出异常而仅仅传回一个NULL指针，可以用new的无异常版本：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则是两个宏，在Include目录的xstddef文件中定义:
#define _THROW0() throw ()
#define _THROW1(x) throw (x)
newop.cpp和newop2.cpp对应的目标模块被打包进标准C++库中。标准C++库有若干个版本: libcp.lib(单线程静态版)、libcpd.lib(单线程静态调试版)、libcpmt.lib(多线程静态版)、libcpmtd.lib(多线程静态调试版)、msvcprt.lib(多线程动态版的导入库)，msvcprtd.lib(多线程动态调试版的导入库)，这些库与相应版本的C标准库一起使用，比如libcp.lib与libc.lib搭配。另外，VC6.0在new.cpp还定义了一个operator new，原型如下 :
void * operator new( unsigned int cb )
而new.cpp对应的目标模块却是被打包进C标准库中的(是不是有点奇怪?)。
一般来说，程序员不会显式指定链接C++标准库，可是当程序中确实使用了标准C++库时链接器却能聪明地把相应的C++标准库文件加进输入文件列表，这是为什么？其实任何一个C++标准头文件都会直接或间接地包含use_ansi.h文件，打开它一看便什么都清楚了(源码之前，了无秘密) :
/***
*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
现在我们用实际代码来测试一下new会不会抛出异常，建一个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;
}
根据VC6.0编译器与链接器的做法(请参考《为什么会出现LNK2005"符号已定义"的链接错误？》)，链接器会首先在C++标准库中解析符号，然后才是C标准库，所以如果开发者没有自定义operator new的话最后程序链接的应该是C++标准库中newop.obj和newop2.obj模块里的代码。可是程序运行的结果却是:
new(nothrow) BigClass, returned a NULL pointer
显然程序始终未抛出bad_alloc异常。单步跟踪观察，发现第1个和第3个new实际上调用了new.cpp里的operator new，而第二个new(nothrow)则正确地调用了newop2.cpp定义的版本。很难理解是吧？但是当你用
dumpbin /SYMBOLS libcp.lib
dump出libcp.lib所有的符号信息时，你会发现其中的newop.obj模块没有定义任何符号(其它版本也一样)。不可思议！newop.cpp的实现代码明明写在那儿，怎么会....？让我们再仔细看看newop.cpp，咦，operator new的定义被包裹在一个#if...#endif块中:
#if !defined(_MSC_EXTENSIONS)
...
...
void *__cdecl operator new(size_t size) _THROW1(_STD bad_alloc)
{
...
...
}
#endif
哦，原来需要_MSC_EXTENSIONS宏未定义，实现代码才是有效的啊。那么这个宏是什么意思？其实Visual C++在语言层面上对ANSI C标准做了一些特殊的扩展，定义_MSC_EXTENSIONS意味着编译器支持这样的扩展，没有定义它编译器就会严格按照ANSI C标准来编译程序。实际上如果指定了编译选项/Ze编译器就会自动定义这个宏，指定/Za则不会，而且/Ze是缺省选项。作者猜想Visual Studio的开发人员在build标准C++库时很可能没有指定/Za，导致newop.cpp中的operator new定义被无情抛弃。是他们的疏漏吗？我看未必，大家可以试试用/Za选项去编译那些标准库文件，看看有多少编译不通过。VC标准库的实现用了很多微软扩展的语言特性，不指定/Za是情有可原的，我不明白的是newop.cpp的作者(好象是P.J. Plauger老人家)为什么会加上一个如此愚蠢的"#if !defined(_MSC_EXTENSIONS)"，因为实在看不出这个operator new定义与_MSC_EXTENSIONS有什么冲突的地方。
既然标准C++库里的newop.obj是个空壳，那我们就只好自己动手丰衣足食了。把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宏，为什么这么做呢？因为dbgint.h属于内部头文件，VC不希望应用程序用到它，便在文件中埋伏了这么一段:
#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 */
可我们确确实实是想build标准库(的一部分)，所以只好强行突破这个限制了。然后编译test.cpp:
cl /c /GX test.cpp
最后进行链接:
link test.obj newop.obj
这时再运行test.exe输出的结果就是
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却表现良好，原因是VC7.1的newop.cpp和newaop.cpp(数组版)取消了那个愚的"#if !defined(_MSC_EXTENSIONS)"，于是标准C++库中的newop.obj和newaop.obj模块都实实在在地有了相应代码。另外，nothrow版的定义也分别转移到了newopnt.cpp和newaopnt.cpp中。
后记: 作者在2001年便碰到过这个问题，百思不得其解，于是在CSDN论坛上发问，也不见答复。从此便搁置一旁，直到最近因探究LNK2005链接错误而彻底弄清楚VC链接器解析符号的规则后，才意识到二者或有联系。于是重拾旧疑，顺藤而上，果然问题就迎刃而解。此题虽小，功夫却做足，最后总算水落石出，解除了4年的积惑。
另一篇文章(网上被大量转载,来源不可知,我觉得这篇文章有些内容不一定正确):
为什么会出现LNK2005"符号已定义"的链接错误?
许多Visual C++的使用者都碰到过LNK2005:symbol already defined和LNK1169:one or more multiply defined symbols found这样的链接错误，而且通常是在使用第三方库时遇到的。对于这个问题，有的朋友可能不知其然，而有的朋友可能知其然却不知其所以然，那么本文就试图为大家彻底解开关于它的种种疑惑。
大家都知道，从C/C++源程序到可执行文件要经历两个阶段:(1)编译器将源文件编译成汇编代码，然后由汇编器(assembler)翻译成机器指令(再加上其它相关信息)后输出到一个个目标文件(object file,VC的编译器编译出的目标文件默认的后缀名是.obj)中；(2)链接器(linker)将一个个的目标文件(或许还会有若干程序库)链接在一起生成一个完整的可执行文件。
编译器编译源文件时会把源文件的全局符号(global symbol)分成强(strong)和弱(weak)两类传给汇编器，而随后汇编器则将强弱信息编码并保存在目标文件的符号表中。那么何谓强弱呢？编译器认为函数与初始化了的全局变量都是强符号，而未初始化的全局变量则成了弱符号。比如有这么个源文件:
extern int errorno;
int buf[2] = {1,2};
int *p;
int main()
{
return 0;
}
其中main、buf是强符号，p是弱符号，而errorno则非强非弱，因为它只是个外部变量的使用声明。
有了强弱符号的概念，我们就可以看看链接器是如何处理与选择被多次定义过的全局符号:
规则1: 不允许强符号被多次定义(即不同的目标文件中不能有同名的强符号)；
规则2: 如果一个符号在某个目标文件中是强符号，在其它文件中都是弱符号，那么选择强符号；
规则3: 如果一个符号在所有目标文件中都是弱符号，那么选择其中任意一个；
由上可知多个目标文件不能重复定义同名的函数与初始化了的全局变量，否则必然导致LNK2005和LNK1169两种链接错误。可是，有的时候我们并没有在自己的程序中发现这样的重定义现象，却也遇到了此种链接错误，这又是何解？嗯，问题稍微有点儿复杂，容我慢慢道来。
众所周知，ANSI C/C++ 定义了相当多的标准函数，而它们又分布在许多不同的目标文件中，如果直接以目标文件的形式提供给程序员使用的话，就需要他们确切地知道哪个函数存在于哪个目标文件中，并且在链接时显式地指定目标文件名才能成功地生成可执行文件，显然这是一个巨大的负担。所以C语言提供了一种将多个目标文件打包成一个文件的机制，这就是静态程序库(static library)。开发者在链接时只需指定程序库的文件名，链接器就会自动到程序库中寻找那些应用程序确实用到的目标模块，并把(且只把)它们从库中拷贝出来参与构建可执行文件。几乎所有的C/C++开发系统都会把标准函数打包成标准库提供给开发者使用(有不这么做的吗？)。
程序库为开发者带来了方便，但同时也是某些混乱的根源。我们来看看链接器是如何解析(resolve)对程序库的引用的。
在符号解析(symbol resolution)阶段，链接器按照所有目标文件和库文件出现在命令行中的顺序从左至右依次扫描它们，在此期间它要维护若干个集合:(1)集合E是将被合并到一起组成可执行文件的所有目标文件集合；(2)集合U是未解析符号(unresolved symbols，比如已经被引用但是还未被定义的符号)的集合；(3)集合D是所有之前已被加入到E的目标文件定义的符号集合。一开始，E、U、D都是空的。
(1): 对命令行中的每一个输入文件f，链接器确定它是目标文件还是库文件，如果它是目标文件，就把f加入到E，并把f中未解析的符号和已定义的符号分别加入到U、D集合中，然后处理下一个输入文件。
(2): 如果f是一个库文件，链接器会尝试把U中的所有未解析符号与f中各目标模块定义的符号进行匹配。如果某个目标模块m定义了一个U中的未解析符号，那么就把m加入到E中，并把m中未解析的符号和已定义的符号分别加入到U、D集合中。不断地对f中的所有目标模块重复这个过程直至到达一个不动点(fixed point)，此时U和D不再变化。而那些未加入到E中的f里的目标模块就被简单地丢弃，链接器继续处理下一输入文件。
(3): 如果处理过程中往D加入一个已存在的符号，或者当扫描完所有输入文件时U非空，链接器报错并停止动作。否则，它把E中的所有目标文件合并在一起生成可执行文件。
VC带的编译器名字叫cl.exe，它有这么几个与标准程序库有关的选项: /ML、/MLd、/MT、/MTd、/MD、/MDd。这些选项告诉编译器应用程序想使用什么版本的C标准程序库。/ML(缺省选项)对应单线程静态版的标准程序库(libc.lib)；/MT对应多线程静态版标准库(libcmt.lib)，此时编译器会自动定义_MT宏；/MD对应多线程DLL版(导入库msvcrt.lib，DLL是msvcrt.dll)，编译器自动定义_MT和_DLL两个宏。后面加d的选项都会让编译器自动多定义一个_DEBUG宏，表示要使用对应标准库的调试版，因此/MLd对应调试版单线程静态标准库(libcd.lib)，/MTd对应调试版多线程静态标准库(libcmtd.lib)，/MDd对应调试版多线程DLL标准库(导入库msvcrtd.lib，DLL是msvcrtd.dll)。虽然我们的确在编译时明白无误地告诉了编译器应用程序希望使用什么版本的标准库，可是当编译器干完了活，轮到链接器开工时它又如何得知一个个目标文件到底在思念谁？为了传递相思，我们的编译器就干了点秘密的勾当。在cl编译出的目标文件中会有一个专门的区域(关心这个区域到底在文件中什么地方的朋友可以参考COFF和PE文件格式)存放一些指导链接器如何工作的信息，其中有一种就叫缺省库(default library)，这些信息指定了一个或多个库文件名，告诉链接器在扫描的时候也把它们加入到输入文件列表中(当然顺序位于在命令行中被指定的输入文件之后)。说到这里，我们先来做个小实验。写个顶顶简单的程序，然后保存为main.c :
/* main.c */
int main() { return 0; }
用下面这个命令编译main.c(什么？你从不用命令行来编译程序？这个......) :
cl /c main.c
/c是告诉cl只编译源文件，不用链接。因为/ML是缺省选项，所以上述命令也相当于: cl /c /ML main.c 。如果没什么问题的话(要出了问题才是活见鬼！当然除非你的环境变量没有设置好，这时你应该去VC的bin目录下找到vcvars32.bat文件然后运行它。)，当前目录下会出现一个main.obj文件，这就是我们可爱的目标文件。随便用一个文本编辑器打开它(是的，文本编辑器，大胆地去做别害怕)，搜索"defaultlib"字符串，通常你就会看到这样的东西: "-defaultlib:LIBC -defaultlib:OLDNAMES"。啊哈，没错，这就
是保存在目标文件中的缺省库信息。我们的目标文件显然指定了两个缺省库，一个是单线程静态版标准库libc.lib(这与/ML选项相符)，另外一个是oldnames.lib(它是为了兼容微软以前的C/C++开发系统)。
VC的链接器是link.exe，因为main.obj保存了缺省库信息，所以可以用
link main.obj libc.lib
或者
link main.obj
来生成可执行文件main.exe，这两个命令是等价的。但是如果你用
link main.obj libcd.lib
的话，链接器会给出一个警告: "warning LNK4098: defaultlib "LIBC" conflicts with use of other libs; use /NODEFAULTLIB:library"，因为你显式指定的标准库版本与目标文件的缺省值不一致。通常来说，应该保证链接器合并的所有目标文件指定的缺省标准库版本一致，否则编译器一定会给出上面的警告，而LNK2005和LNK1169链接错误则有时会出现有时不会。那么这个有时到底是什么时候？呵呵，别着急，下面的一切正是为喜欢追根究底的你准备的。
建一个源文件，就叫mylib.c，内容如下:
/* mylib.c */
#include <stdio.h>
void foo()
{
printf("%s","I am from mylib!\n");
}
用
cl /c /MLd mylib.c
命令编译，注意/MLd选项是指定libcd.lib为默认标准库。lib.exe是VC自带的用于将目标文件打包成程序库的命令，所以我们可以用
lib /OUT:my.lib mylib.obj
将mylib.obj打包成库，输出的库文件名是my.lib。接下来把main.c改成:
/* main.c */
void foo();
int main()
{
foo();
return 0;
}
用
cl /c main.c
编译，然后用
link main.obj my.lib
进行链接。这个命令能够成功地生成main.exe而不会产生LNK2005和LNK1169链接错误，你仅仅是得到了一条警告信息:"warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs; use /NODEFAULTLIB:library"。我们根据前文所述的扫描规则来分析一下链接器此时做了些啥。
一开始E、U、D都是空集，链接器首先扫描到main.obj，把它加入E集合，同时把未解析的foo加入U，把main加入D，而且因为main.obj的默认标准库是libc.lib，所以它被加入到当前输入文件列表的末尾。接着扫描my.lib，因为这是个库，所以会拿当前U中的所有符号(当然现在就一个foo)与my.lib中的所有目标模块(当然也只有一个mylib.obj)依次匹配，看是否有模块定义了U中的符号。结果mylib.obj确实定义了foo，于是它被加入到E，foo从U转移到D，mylib.obj引用的printf加入到U，同样地，mylib.obj指定的默认标准库是libcd.lib，它也被加到当前输入文件列表的末尾(在libc.lib的后面)。不断地在my.lib库的各模块上进行迭代以匹配U中的符号，直到U、D都不再变化。很明显，现在就已经到达了这么一个不动点，所以接着扫描下一个输入文件，就是libc.lib。链接器发现libc.lib里的printf.obj里定义有printf，于是printf从U移到D，而printf.obj被加入到E，它定义的所有符号加入到D，它里头的未解析符号加入到U。链接器还会把每个程序都要用到的一些初始化操作所在的目标模块(比如crt0.obj等)及它们所引用的模块(比如malloc.obj、free.obj等)自动加入到E中，并更新U和D以反应这个变化。事实上，标准库各目标模块里的未解析符号都可以在库内其它模块中找到定义，因此当链接器处理完libc.lib时，U一定是空的。最后处理libcd.lib，因为此时U已经为空，所以链接器会抛弃它里面的所有目标模块从而结束扫描，然后合并E中的目标模块并输出可执行文件。
上文描述了虽然各目标模块指定了不同版本的缺省标准库但仍然链接成功的例子，接下来你将目睹因为这种不严谨而导致的悲惨失败。
修改mylib.c成这个样子:
#include <crtdbg.h>
void foo()
{
// just a test , don't care memory leak
_malloc_dbg( 1, _NORMAL_BLOCK, __FILE__, __LINE__ );
}
其中_malloc_dbg不是ANSI C的标准库函数，它是VC标准库提供的malloc的调试版，与相关函数配套能帮助开发者抓各种内存错误。使用它一定要定义_DEBUG宏，否则预处理器会把它自动转为malloc。继续用
cl /c /MLd mylib.c
lib /OUT:my.lib mylib.obj
编译打包。当再次用
link main.obj my.lib
进行链接时，我们看到了什么？天哪，一堆的LNK2005加上个贵为"fatal error"的LNK1169垫底，当然还少不了那个LNK4098。链接器是不是疯了？不，你冤枉可怜的链接器了，我拍胸脯保证它可是一直在尽心尽责地照章办事。
一开始E、U、D为空，链接器扫描main.obj，把它加入E，把foo加入U，把main加入D，把libc.lib加入到当前输入文件列表的末尾。接着扫描my.lib，foo从U转移到D，_malloc_dbg加入到U，libcd.lib加到当前输入文件列表的尾部。然后扫描libc.lib，这时会发现libc.lib里任何一个目标模块都没有定义_malloc_dbg(它只在调试版的标准库中存在)，所以不会有任何一个模块因为_malloc_dbg而加入E，但是每个程序都要用到的初始化模块(如crt0.obj等)及它们所引用的模块(比如malloc.obj、free.obj等)还是会自动加入到E中，同时U和D被更新以反应这个变化。当链接器处理完libc.lib时，U只剩_malloc_dbg这一个符号。最后处理libcd.lib，发现dbgheap.obj定义了_malloc_dbg，于是dbgheap.obj加入到E，它里头的未解析符号加入U，它定义的所有其它符号也加入D，这时灾难便来了。之前malloc等符号已经在D中(随着libc.lib里的malloc.obj加入E而加入的)，而dbgheap.obj又定义了包括malloc在内的许多同名符号，这引发了重定义冲突，链接器只好中断工作并报告错误。
现在我们该知道，链接器完全没有责任，责任在我们自己的身上。是我们粗心地把缺省标准库版本不一致的目标文件(main.obj)与程序库(my.lib)链接起来，导致了大灾难。解决办法很简单，要么用/MLd选项来重编译main.c；要么用/ML选项重编译mylib.c。
在上述例子中，我们拥有库my.lib的源代码(mylib.c)，所以可以用不同的选项重新编译这些源代码并再次打包。可如果使用的是第三方的库，它并没有提供源代码，那么我们就只有改变自己程序的编译选项来适应这些库了。但是如何知道库中目标模块指定的默认库呢？其实VC提供的一个小工具便可以完成任务，这就是dumpbin.exe。运行下面这个命令
dumpbin /DIRECTIVES my.lib
然后在输出中找那些"Linker Directives"引导的信息，你一定会发现每一处这样的信息都会包含若干个类似"-defaultlib:XXXX"这样的字符串，其中XXXX便代表目标模块指定的缺省库名。
知道了第三方库指定的默认标准库，再用合适的选项编译我们的应用程序，就可以避免LNK2005和LNK1169链接错误。喜欢IDE的朋友，你一样可以到 "Project属性" -> "C/C++" -> "代码生成(code generation)" -> "运行时库(run-time library)" 项下设置应用程序的默认标准库版本，这与命令行选项的效果是一样的。
好文章还不是一般的多:
Under The Hood, July 1997
http://comcamp.diy.myrice.com/techarticles/vc/0010.htm
为什么全局变量没有初始化?
http://comcamp.diy.myrice.com/techarticles/vc/0011.htm
链接一个静态LIB,不在客户端代码中使用它的任何变量和代码,但要让这个LIB的全局变量被初始化的方法是:
这个链接库头文件应该这么写:
extern CMyClass *g_pObject ;
static void *__dummy = (void*)g_pObject ;
// lib.cpp
CMyClass *g_pObject = CMyClass::Instance() ; // Singleton
__dummy会出现在任何包含这个头文件的CPP文件的OBJ中,所以LINKER会把静态库中的g_pObject链接到Exe中,包括它的构造和析构
<iostream>很有意思,其中有一行
static ios_base::Init _Ios_init;
ios_base::Init是个类,在类的构造中判断构造是否第一次被调用,如果是,则初始化cout,cin,cerr等
在类的析构中判断这是不是最后一次构造,如果是,则调用cout.flush() .... (basic_ostream等的析构并没有调用flush)
具体怎么判断是否第一次调用构造,是否最后一次调用析构,那是用一个int的静态类成员来计算...
其实这样会增加exe文件的尺寸,降低程序启动速度....