都能得到结构s关联的GUID：("93A1665E-C9FA-4147-AC3A-3CC855281AF8")

1.无局部变量

a.刚进入函数时:

b.然后在函数体一开始执行了以下代码之后:

push ebp

mov   ebp,esp

sub   esp,0x8

......

a.刚进入函数时:

b.然后在函数体一开始执行了以下代码之后:

push ebp

mov   ebp,esp

sub   esp,( MIN(X)*0x10+0x8 );满足:MIN(X)*0x10>=N*0x4

......

也就是说,跟据局部变量的多少,临时空间的开辟是以0x10为增长量,也许是为了内存对齐吧,而且不同的编译器实现也不一样.比如有5个int型临时变量则sub esp,0x28;有8个int型临时变量也是sub esp,0x28;到有9个int型临时变量则为sub esp,0x38

进入main函数的时候，
1）保存ebp指针
2）使得ebp->esp
3）保持现场ebx，esi，edi
4）进入一般函数的时候，push参数，例如有n个参数 esp = esp - 4*n
5）push函数返回地址 esp = esp -4
6）调用函数 EIP指向函数地址，jmp 函数地址
7）Push ebp 保存 (故有[ebp+8]就是第一个参数的内容)
8）使得ebp ->esp, esp = esp - 40h - 临时变量需要字节数（有字节对齐问题）
9）保持现场ebx，esi，edi
10）返回值=》eax
11）恢复现场，就是依次pop出edi，esi，ebx，
12）Esp = ebp
13）Pop ebp
14）pop 函数返回地址（即ret），EIP指向下个指令地址 esp = esp +4
15）Esp + n*4 (每个字有4个字节)；push是按字操作的，32位机器

知道这些后，程序的溢出就比较容易做了。

题目：

 int* p = 0x00000000; // pointer to NULL

 puts( "hello ");

 __try{

 puts( "in try ");

 __try{

 puts( "in try ");

 *p = 13; // causes an access violation exception;

 }__finally{

 puts( "in finally ");

 }

 }__except(puts( "in filter "), 1){

 puts( "in except ");

 }

 puts( "world ");

 /*

 hello

 in try

 in try

 in filter

 in finally

 in except

 world

 */

上面的题目，我把答案列了出来。

常用Ｃ＋＋的朋友，应该没见过__try这种形式的语句，下面我把try，catch; __try,__finally; __try, __except这三对异常处理使用标示逐一说明

本文参考了如下博文：

http://www.cnblogs.com/wenziqi/archive/2010/08/26/1809074.html

http://blog.csdn.net/lvwenshuai/article/details/6163342

http://topic.csdn.net/t/20030527/10/1838724.html

http://zhidao.baidu.com/question/183400727.html

• C++ 异常处理：try，catch

try { // 可能出错的语句 // 如果有错，就—— throw ... // 初始化一个异常对象（exception object） } catch( 类型名 [形参名] ) /* 异常说明符（exception specifier）*/ { } catch( 类型名 [形参名] ) { }

C++的异常处理很简单，就是如上的三个关键字，注意C++中throw，catch之后没有Java等语言中的finally。

Q: 为何C++不提供“finally”结构？ 
A: 因为C++提供了另一种机制，完全可以取代finally，而且这种机制几乎总要比finally工作得更好：就是——“分配资源即初始化”。（见《The C++ Programming Language》14.4节）基本的想法是，用一个局部对象来封装一个资源，这样一来局部对象的析构函数就可以自动释放资源。这样，程序员就不会“忘记释放资源”了。 [译注：因为C++的对象“生命周期”机制替他记住了 :O) ] 下面是一个例子：

class File_handle {

 FILE* p;

 public:

 File_handle(const char* n, const char* a)

 { p = fopen(n,a); if (p==0) throw Open_error(errno); }

 File_handle(FILE* pp)

 { p = pp; if (p==0) throw Open_error(errno); }

 ~File_handle() { fclose(p); }

 operator FILE*() { return p; }

 // ...

 };

 void f(const char* fn)

 {

 File_handle f(fn,"rw"); // open fn for reading and writing

 // use file through f

 }

在一个系统中，每一样资源都需要一个“资源局柄”对象，但我们不必为每一个资源都写一个“finally”语句。在实作的系统中，资源的获取和释放的次数远远多于资源的种类，所以“资源分配即初始化”机制产生的代码要比“finally”机制少。

好了，接下来，看另外两组异常模型机制，它们是Windows系列操作系统平台上提供的SEH模型，也就是说在C++中调用的时候，其实是调用Windows的API

SEH,又称结构化异常处理.是设计Windows操作系统时提出一个种处理异常的方法。

• __try, __except

这组异常处理机制和C++的很相像，只是关键字是except而不是catch

catch 和 except 的一点不同： catch关键字后面往往好像接受一个函数参数一样，可以是各种类型的异常数据对象；但是__except关键字则不同，它后面跟的却是一个表达式（可以是各种类型的表达式）

下面是一个例子：

void main()

{

 puts("hello");

 // 定义受监控的代码模块

 __try

 {

 puts("in try");

 }

 //定义异常处理模块

 __except(1)

 {

 puts("in except");

 }

 puts("world");

}

1. 受监控的代码模块被执行（也即__try定义的模块代码）； 
2. 如果上面的代码执行过程中，没有出现异常的话，那么控制流将转入到__except子句之后的代码模块中； 
3. 否则，如果出现异常的话，那么控制流将进入到__except后面的表达式中，也即首先计算这个表达式的值，之后再根据这个值，来决定做出相应的处理。

EXCEPTION_CONTINUE_EXECUTION (–1) 异常被忽略，控制流将在异常出现的点之后，继续恢复运行。 
EXCEPTION_CONTINUE_SEARCH (0) 异常不被识别，也即当前的这个__except模块不是这个异常错误所对应的正确的异常处理模块。系统将继续到上一层的try-except域中继续查找一个恰当的__except模块。 
EXCEPTION_EXECUTE_HANDLER (1) 异常已经被识别，也即当前的这个异常错误，系统已经找到了并能够确认，这个__except模块就是正确的异常处理模块。控制流将进入到__except模块中。

小结：

（1） C++异常模型用try-catch语法定义，而SEH异常模型则用try-except语法；

（2） 与C++异常模型相似，try-except也支持多层的try-except嵌套。

（3） 与C++异常模型不同的是，try-except模型中，一个try块只能是有一个except块；而C++异常模型中，一个try块可以有多个catch块。

（4） 与C++异常模型相似，try-except模型中，查找搜索异常模块的规则也是逐级向上进行的。但是稍有区别的是，C++异常模型是按照异常对象的类型来进行匹配查找的；而try-except模型则不同，它通过一个表达式的值来进行判断。如果表达式的值为1（EXCEPTION_EXECUTE_HANDLER），表示找到了异常处理模块；如果值为0（EXCEPTION_CONTINUE_SEARCH），表示继续向上一层的try-except域中继续查找其它可能匹配的异常处理模块；如果值为-1（EXCEPTION_CONTINUE_EXECUTION），表示忽略这个异常，注意这个值一般很少用，因为它很容易导致程序难以预测的结果，例如，死循环，甚至导致程序的崩溃等。

（5） __except关键字后面跟的表达式，它可以是各种类型的表达式，例如，它可以是一个函数调用，或是一个条件表达式，或是一个逗号表达式，或干脆就是一个整型常量等等。最常用的是一个函数表达式，并且通过利用GetExceptionCode()或GetExceptionInformation ()函数来获取当前的异常错误信息，便于程序员有效控制异常错误的分类处理。

（6） SEH异常处理模型中，异常被划分为两大类：系统异常和软件异常。其中软件异常通过RaiseException()函数抛出。RaiseException()函数的作用类似于C++异常模型中的throw语句。

详细的请参看：http://www.cnblogs.com/wenziqi/archive/2010/08/26/1809074.html

• __try, __finally

try-finally语句的语法与try-except很类似，稍有不同的是，__finally后面没有一个表达式，这是因为try- finally语句的作用不是用于异常处理，所以它不需要一个表达式来判断当前异常错误的种类。另外，与try-except语句类似，try- finally也可以是多层嵌套的，并且一个函数内可以有多个try-finally语句，不管它是嵌套的，或是平行的。当然，try-finally多层嵌套也可以是跨函数的。

最关键的一点： “不管在何种情况下，在离开当前的作用域时，finally块区域内的代码都将会被执行到”

void tmain()

{

 puts("hello");

 __try

 {

 puts("__try块中");

 // 注意，下面return语句直接让函数返回了

 return;

 }

 __finally

 {

 puts("__finally块中");

 }

 puts("world");

｝

上面的程序运行结果如下： 
hello 
__try块中 
__finally块中 
Press any key to continue

小结：

__finally块被执行的流程时，无外乎三种情况。

第一种就是顺序执行到__finally块区域内的代码，这种情况很简单，容易理解；

第二种就是goto语句或return语句引发的程序控制流离开当前__try块作用域时，系统自动完成对__finally块代码的调用；

第三种就是由于在__try块中出现异常时，导致程序控制流离开当前__try块作用域，这种情况下也是由系统自动完成对__finally块的调用。

无论是第 2种，还是第3种情况，毫无疑问，它们都会引起很大的系统开销，编译器在编译此类程序代码时，它会为这两种情况准备很多的额外代码。

一般第2种情况，被称为“局部展开（LocalUnwinding）”；第3种情况，被称为“全局展开（GlobalUnwinding）”。在后面阐述SEH实现的时候会详细分析到这一点。

第3种情况，也即由于出现异常而导致的“全局展开”，对于程序员而言，这也许是无法避免的，因为你在利用异常处理机制提高程序可靠健壮性的同时，不可避免的会引起性能上其它的一些开销。呵呵！这世界其实也算瞒公平的，有得必有失。

到此，本文开头的那段代码的结果就没有任何悬念了，O(∩_∩)O哈哈~，每天进步一点点~~~~~~~~

转自：http://shijuanfeng.blogbus.com/logs/178616871.html

基本使用

对于下面这样的一个简单程序test.cpp：

int main()
{
	int* p1 = new int;
	char* p2 = new char[10];
	return 0;
}

我们的基本需求当然是对于该程序报告存在两处内存泄漏。要做到这点的话，非常简单，只要把debug_new.cpp也编译、链接进去就可以了。在Linux下，我们使用：

g++ test.cpp debug_new.cpp -o test

输出结果如下所示：

Leaked object at 0x805e438 (size 10, <Unknown>:0)
Leaked object at 0x805e410 (size 4, <Unknown>:0)

如果我们需要更清晰的报告，也很简单，在test.cpp开头加一行

#include "debug_new.h"

即可。添加该行后的输出如下：

Leaked object at 0x805e438 (size 10, test.cpp:5)
Leaked object at 0x805e410 (size 4, test.cpp:4)

非常简单！

回页首

背景知识

在new/delete操作中，C++为用户产生了对operator new和operator delete的调用。这是用户不能改变的。operator new和operator delete的原型如下所示：

void *operator new(size_t) throw(std::bad_alloc);
void *operator new[](size_t) throw(std::bad_alloc);
void operator delete(void*) throw();
void operator delete[](void*) throw();

对于"new int"，编译器会产生一个调用"operator new(sizeof(int))"，而对于"new char[10]"，编译器会产生"operator new[](sizeof(char) * 10)"（如果new后面跟的是一个类名的话，当然还要调用该类的构造函数）。类似地，对于"delete ptr"和"delete[] ptr"，编译器会产生"operator delete(ptr)"调用和"operator delete[](ptr)"调用（如果ptr的类型是指向对象的指针的话，那在operator delete之前还要调用对象的析构函数）。当用户没有提供这些操作符时，编译系统自动提供其定义；而当用户自己提供了这些操作符时，就覆盖了编译系统提供的版本，从而可获得对动态内存分配操作的精确跟踪和控制。

同时，我们还可以使用placement new操作符来调整operator new的行为。所谓placement new，是指带有附加参数的new操作符，比如，当我们提供了一个原型为

void* operator new(size_t size, const char* file, int line);

的操作符时，我们就可以使用"new("hello", 123) int"来产生一个调用"operator new(sizeof(int), "hello", 123)"。这可以是相当灵活的。又如，C++标准要求编译器提供的一个placement new操作符是

void* operator new(size_t size, const std::nothrow_t&);

其中，nothrow_t通常是一个空结构（定义为"struct nothrow_t {};"），其唯一目的是提供编译器一个可根据重载规则识别具体调用的类型。用户一般简单地使用"new(std::nothrow) 类型"（nothrow是一个nothrow_t类型的常量）来调用这个placement new操作符。它与标准new的区别是，new在分配内存失败时会抛出异常，而"new(std::nothrow)"在分配内存失败时会返回一个空指针。

要注意的是，没有对应的"delete(std::nothrow) ptr"的语法；不过后文会提到另一个相关问题。

要进一步了解以上关于C++语言特性的信息，请参阅[Stroustrup1997]，特别是6.2.6、10.4.11、15.6、19.4.5和B.3.4节。这些C++语言特性是理解本实现的关键。

回页首

检测原理

和其它一些内存泄漏检测的方式类似，debug_new中提供了operator new重载，并使用了宏在用户程序中进行替换。debug_new.h中的相关部分如下：

void* operator new(size_t size, const char* file, int line);
void* operator new[](size_t size, const char* file, int line);
#define new DEBUG_NEW
#define DEBUG_NEW new(__FILE__, __LINE__)

拿上面加入debug_new.h包含后的test.cpp来说，"new char[10]"在预处理后会变成"new("test.cpp", 4) char[10]"，编译器会据此产生一个"operator new[](sizeof(char) * 10, "test.cpp", 4)"调用。通过在debug_new.cpp中自定义"operator new(size_t, const char*, int)"和"operator delete(void*)"（以及"operator new[]…"和"operator delete[]…"；为避免行文累赘，以下不特别指出，说到operator new和operator delete均同时包含数组版本），我可以跟踪所有的内存分配调用，并在指定的检查点上对不匹配的new和delete操作进行报警。实现可以相当简单，用map记录所有分配的内存指针就可以了：new时往map里加一个指针及其对应的信息，delete时删除指针及对应的信息；delete时如果map里不存在该指针为错误删除；程序退出时如果map里还存在未删除的指针则说明有内存泄漏。

不过，如果不包含debug_new.h，这种方法就起不了作用了。不仅如此，部分文件包含debug_new.h，部分不包含debug_new.h都是不可行的。因为虽然我们使用了两种不同的operator new --"operator new(size_t, const char*, int)"和"operator new(size_t)"-- 但可用的"operator delete"还是只有一种！使用我们自定义的"operator delete"，当我们删除由"operator new(size_t)"分配的指针时，程序将认为被删除的是一个非法指针！我们处于一个两难境地：要么对这种情况产生误报，要么对重复删除同一指针两次不予报警：都不是可接受的良好行为。

看来，自定义全局"operator new(size_t)"也是不可避免的了。在debug_new中，我是这样做的：

void* operator new(size_t size)
{
	return operator new(size, "<Unknown>", 0);
}

但前面描述的方式去实现内存泄漏检测器，在某些C++的实现中（如GCC 2.95.3中带的SGI STL）工作正常，但在另外一些实现中会莫名其妙地崩溃。原因也不复杂，SGI STL使用了内存池，一次分配一大片内存，因而使利用map成为可能；但在其他的实现可能没这样做，在map中添加数据会调用operator new，而operator new会在map中添加数据，从而构成一个死循环，导致内存溢出，应用程序立即崩溃。因此，我们不得不停止使用方便的STL模板，而使用手工构建的数据结构：

struct new_ptr_list_t
{
	new_ptr_list_t*		next;
	const char*			file;
	int					line;
	size_t				size;
};

我最初的实现方法就是每次在使用new分配内存时，调用malloc多分配 sizeof(new_ptr_list_t) 个字节，把分配的内存全部串成一个一个链表（利用next字段），把文件名、行号、对象大小信息分别存入file、line和size字段中，然后返回(malloc返回的指针 + sizeof(new_ptr_list_t))。在delete时，则在链表中搜索，如果找到的话（(char*)链表指针 + sizeof(new_ptr_list_t) == 待释放的指针），则调整链表、释放内存，找不到的话报告删除非法指针并abort。

至于自动检测内存泄漏，我的做法是生成一个静态全局对象（根据C++的对象生命期，在程序初始化时会调用该对象的构造函数，在其退出时会调用该对象的析构函数），在其析构函数中调用检测内存泄漏的函数。用户手工调用内存泄漏检测函数当然也是可以的。

基本实现大体就是如此。

回页首

可用性改进

上述方案最初工作得相当好，直到我开始创建大量的对象为止。由于每次delete时需要在链表中进行搜索，平均搜索次数为(链表长度/2)，程序很快就慢得像乌龟爬。虽说只是用于调试，速度太慢也是不能接受的。因此，我做了一个小更改，把指向链表头部的new_ptr_list改成了一个数组，一个对象指针放在哪一个链表中则由它的哈希值决定。--用户可以更改宏DEBUG_NEW_HASH和DEBUG_NEW_HASHTABLESIZE的定义来调整debug_new的行为。他们的当前值是我测试下来比较满意的定义。

使用中我们发现，在某些特殊情况下（请直接参看debug_new.cpp中关于DEBUG_NEW_FILENAME_LEN部分的注释），文件名指针会失效。因此，目前的debug_new的缺省行为会复制文件名的头20个字符，而不只是存储文件名的指针。另外，请注意原先new_ptr_list_t的长度为16字节，现在是32字节，都能保证在通常情况下内存对齐。

此外，为了允许程序能和 new(std::nothrow) 一起工作，我也重载了operator new(size_t, const std::nothrow_t&) throw()；不然的话，debug_new会认为对应于 new(nothrow) 的delete调用删除的是一个非法指针。由于debug_new不抛出异常（内存不足时程序直接报警退出），所以这一重载的操作只不过是调用 operator new(size_t) 而已。这就不用多说了。

前面已经提到，要得到精确的内存泄漏检测报告，可以在文件开头包含"debug_new.h"。我的惯常做法可以用作参考：

#ifdef _DEBUG
#include "debug_new.h"
#endif

包含的位置应当尽可能早，除非跟系统的头文件（典型情况是STL的头文件）发生了冲突。在某些情况下，可能会不希望debug_new重定义new，这时可以在包含debug_new.h之前定义DEBUG_NEW_NO_NEW_REDEFINITION，这样的话，在用户应用程序中应使用debug_new来代替new（顺便提一句，没有定义DEBUG_NEW_NO_NEW_REDEFINITION时也可以使用debug_new代替new）。在源文件中也许就该这样写：

#ifdef _DEBUG
#define DEBUG_NEW_NO_NEW_REDEFINITION
#include "debug_new.h"
#else
#define debug_new new
#endif

并在需要追踪内存分配的时候全部使用debug_new（考虑使用全局替换）。

用户可以选择定义DEBUG_NEW_EMULATE_MALLOC，这样debug_new.h会使用debug_new和delete来模拟malloc和free操作，使得用户程序中的malloc和free操作也可以被跟踪。在使用某些编译器的时候（如Digital Mars C++ Compiler 8.29和Borland C++ Compiler 5.5.1），用户必须定义NO_PLACEMENT_DELETE，否则编译无法通过。用户还可以使用两个全局布尔量来调整debug_new的行为：new_verbose_flag，缺省为false，定义为true时能在每次new/delete时向标准错误输出显示跟踪信息；new_autocheck_flag，缺省为true，即在程序退出时自动调用check_leaks检查内存泄漏，改为false的话用户必须手工调用check_leaks来检查内存泄漏。

需要注意的一点是，由于自动调用check_leaks是在debug_new.cpp中的静态对象析构时，因此不能保证用户的全局对象的析构操作发生在check_leaks调用之前。对于Windows上的MSVC，我使用了"#pragma init_seg(lib)"来调整对象分配释放的顺序，但很遗憾，我不知道在其他的一些编译器中（特别是，我没能成功地在GCC中解决这一问题）怎么做到这一点。为了减少误报警，我采取的方式是在自动调用了check_leaks之后设new_verbose_flag为true；这样，就算误报告了内存泄漏，随后的delete操作还是会被打印显示出来。只要泄漏报告和delete报告的内容一致，我们仍可以判断出没有发生内存泄漏。

Debug_new也能检测对同一指针重复调用delete（或delete无效指针）的错误。程序将显示错误的指针值，并强制调用abort退出。

还有一个问题是异常处理。这值得用专门的一节来进行说明。

回页首

构造函数中的异常

我们看一下以下的简单程序示例：

#include <stdexcept>
#include <stdio.h>
void* operator new(size_t size, int line)
{
	printf("Allocate %u bytes on line %d\\n", size, line);
	return operator new(size);
}
class Obj {
public:
	Obj(int n);
private:
	int _n;
};
Obj::Obj(int n) : _n(n)
{
	if (n == 0) {
		throw std::runtime_error("0 not allowed");
	}
}
int main()
{
	try {
		Obj* p = new(__LINE__) Obj(0);
		delete p;
	} catch (const std::runtime_error& e) {
		printf("Exception: %s\\n", e.what());
	}
}

看出代码中有什么问题了吗？实际上，如果我们用MSVC编译的话，编译器的警告信息已经告诉我们发生了什么：

test.cpp(27) : warning C4291: 'void *__cdecl operator new(unsigned int,int)' : 
no matching operator delete found; memory will not be freed if initialization throws
 an exception

好，把debug_new.cpp链接进去。运行结果如下：

Allocate 4 bytes on line 27 Exception: 0 not allowed Leaked object at 
 00342BE8 (size 4, <Unknown>:0) 	

啊哦，内存泄漏了不是！

当然，这种情况并非很常见。可是，随着对象越来越复杂，谁能够保证一个对象的子对象的构造函数或者一个对象在构造函数中调用的所有函数都不会抛出异常？并且，解决该问题的方法并不复杂，只是需要编译器对 C++ 标准有较好支持，允许用户定义 placement delete 算符（[C++1998]，5.3.4节；网上可以找到1996年的标准草案，比如下面的网址 http://www.comnets.rwth-aachen.de/doc/c++std/expr.html#expr.new）。在我测试的编译器中，GCC（2.95.3或更高版本，Linux/Windows）和MSVC（6.0或更高版本）没有问题，而Borland C++ Compiler 5.5.1和Digital Mars C++ Compiler（到v8.38为止的所有版本）则不支持该项特性。在上面的例子中，如果编译器支持的话，我们就需要声明并实现 operator delete(void*, int) 来回收new分配的内存。编译器不支持的话，需要使用宏让编译器忽略相关的声明和实现。如果要让debug_new在Borland C++ Compiler 5.5.1或Digital Mars C++ Compiler下编译的话，用户必须定义宏NO_PLACEMENT_DELETE；当然，用户得自己注意小心构造函数中抛出异常这个问题了。

回页首

方案比较

IBM developerWorks上刊载了洪琨先生设计实现的一个Linux上的内存泄漏检测方法（[洪琨2003]）。我的方案与其相比，主要区别如下：

优点：

• 跨平台：只使用标准函数，并且在GCC 2.95.3/3.2（Linux/Windows）、MSVC 6、Digital Mars C++ 8.29、Borland C++ 5.5.1等多个编译器下调试通过。（虽然Linux是我的主要开发平台，但我发现，有时候能在Windows下编译运行代码还是非常方便的。）
• 易用性：由于重载了operator new(size_t)--洪琨先生只重载了operator new(size_t, const char*, int)--即使不包含我的头文件也能检测内存泄漏；程序退出时能自动检测内存泄漏；可以检测用户程序（不包括系统/库文件）中malloc/free产生的内存泄漏。
• 灵活性：有多个灵活的可配置项，可使用宏定义进行编译时选择。
• 可重入性：不使用全局变量，没有嵌套delete问题。
• 异常安全性：在编译器支持的情况下，能够处理构造函数中抛出的异常而不发生内存泄漏。

缺点：

• 单线程模型：跨平台的多线程实现较为麻烦，根据项目的实际需要，也为了代码清晰简单起见，我的方案不是线程安全的；换句话说，如果多个线程中同时进行new或delete操作的话，后果未定义。
• 未实现运行中内存泄漏检测报告机制：没有遇到这个需求J；不过，如果要手工调用check_leaks函数实现的话也不困难，只是跨平台性就有点问题了。
• 不能检测带 [] 算符和不带 [] 算符混用的不匹配：主要也是需求问题（如果要修改实现的话并不困难）。
• 不能在错误的delete调用时显示文件名和行号：应该不是大问题；由于我重载了operator new(size_t)，可以保证delete出错时程序必然有问题，因而我不只是显示警告信息，而且会强制程序abort，可以通过跟踪程序、检查abort时程序的调用栈知道问题出在哪儿。

另外，现在已存在不少商业和Open Source的内存泄漏检测器，本文不打算一一再做比较。Debug_new与它们相比，功能上总的来说仍较弱，但是，其良好的易用性和跨平台性、低廉的附加开销还是具有很大优势的。

回页首

总结和讨论

以上段落基本上已经说明了debug_new的主要特点。下面做一个小小的总结。

重载的算符：

• operator new(size_t, const char*, int)
• operator new[](size_t, const char*, int)
• operator new(size_t)
• operator new[](size_t)
• operator new(size_t, const std::nothrow_t&)
• operator new[](size_t, const std::nothrow_t&)
• operator delete(void*)
• operator delete[](void*)
• operator delete(void*, const char*, int)
• operator delete[](void*, const char*, int)
• operator delete(void*, const std::nothrow_t&)
• operator delete[](void*, const std::nothrow_t&)

提供的函数：

• check_leaks()
  检查是否发生内存泄漏

提供的全局变量

• new_verbose_flag
  是否在new和delete时"罗嗦"地显示信息
• new_autocheck_flag
  是否在程序退出是自动检测一次内存泄漏

可重定义的宏：

• NO_PLACEMENT_DELETE
  假设编译器不支持placement delete（全局有效）
• DEBUG_NEW_NO_NEW_REDEFINITION
  不重定义new，假设用户会自己使用debug_new（包含debug_new.h时有效）
• DEBUG_NEW_EMULATE_MALLOC
  重定义malloc/free，使用new/delete进行模拟（包含debug_new.h时有效）
• DEBUG_NEW_HASH
  改变内存块链表哈希值的算法（编译debug_new.cpp时有效）
• DEBUG_NEW_HASHTABLE_SIZE
  改变内存块链表哈希桶的大小（编译debug_new.cpp时有效）
• DEBUG_NEW_FILENAME_LEN
  如果在分配内存时复制文件名的话，保留的文件名长度；为0时则自动定义DEBUG_NEW_NO_FILENAME_COPY（编译debug_new.cpp时有效；参见文件中的注释）
• DEBUG_NEW_NO_FILENAME_COPY
  分配内存时不进行文件名复制，而只是保存其指针；效率较高（编译debug_new.cpp时有效；参见文件中的注释）

我本人认为，debug_new目前的一个主要缺陷是不支持多线程。对于某一特定平台，要加入多线程支持并不困难，难就难在通用上（当然，条件编译是一个办法，虽然不够优雅）。等到C++标准中包含线程模型时，这个问题也许能比较完美地解决吧。另一个办法是使用像boost这样的程序库中的线程封装类，不过，这又会增加对其它库的依赖性--毕竟boost并不是C++标准的一部分。如果项目本身并不用boost，单为了这一个目的使用另外一个程序库似乎并不值得。因此，我自己暂时就不做这进一步的改进了。

另外一个可能的修改是保留标准operator new的异常行为，使其在内存不足的情况下抛出异常（普通情况）或是返回NULL（nothrow情况），而不是像现在一样终止程序运行（参见debug_new.cpp的源代码）。这一做法的难度主要在于后者：我没想出什么方法，可以保留 new(nothrow) 的语法，同时能够报告文件名和行号，并且还能够使用普通的new。不过，如果不使用标准语法，一律使用debug_new和debug_new_nothrow的话，那还是非常容易实现的。

如果大家有改进意见或其它想法的话，欢迎来信讨论。

debug_new 的源代码目前可以在 dbg_new.zip处下载。

在这篇文章的写完之后，我终于还是实现了一个线程安全的版本。该版本使用了一个轻量级的跨平台互斥体类fast_mutex（目前支持Win32和POSIX线程，在使用GCC（Linux/MinGW）、MSVC时能通过命令行参数自动检测线程类型）。有兴趣的话可在 http://mywebpage.netscape.com/yongweiwu/dbg_new.tgz下载。

参考资料

[C++1998] ISO/IEC 14882. Programming Languages-C++, 1st Edition. International Standardization Organization, International Electrotechnical Commission, American National Standards Institute, and Information Technology Industry Council, 1998

[Stroustrup1997] Bjarne Stroustrup. The C++ Programming Language, 3rd Edition. Addison-Wesley, 1997

[洪琨2003] 洪琨。 《如何在 linux 下检测内存泄漏》，IBM developerWorks 中国网站。

对于内存泄漏，本人深有体会！实习的时候，公司一个项目中就存在内存泄漏问题，项目的代码两非常大，后台进程也比较多，造成内存泄漏的地方比较难找。这次机会是我对如何查找内存泄漏问题，有了一定的经验，后面自己的做了相关实验，在此我分享一下内存泄漏如何调试查找，主要内容如下：

• 1、内存泄漏简介
• 2、Windows平台下的内存泄漏检测
  • 2.1、检测是否存在内存泄漏问题
  • 2.2、定位具体的内存泄漏地方
• 3、Linux平台下的内存泄漏检测 
• 4、总结

其实Windows、Linux下面的内存检测都可以单独开篇详细介绍，方法和工具也远远不止文中介绍到的，我的方法也不是最优的，如果您有更好的方法，也请您告诉我和大家。

1、内存泄漏简介及后果

wikipedia中这样定义内存泄漏：在计算机科学中，内存泄漏指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况。内存泄漏并非指内存在物理上的消失，而是应用程序分配某段内存后，由于设计错误，导致在释放该段内存之前就失去了对该段内存的控制，从而造成了内存的浪费。

最难捉摸也最难检测到的错误之一是内存泄漏，即未能正确释放以前分配的内存的 bug。 只发生一次的小的内存泄漏可能不会被注意，但泄漏大量内存的程序或泄漏日益增多的程序可能会表现出各种征兆：从性能不良（并且逐渐降低）到内存完全用尽。 更糟的是，泄漏的程序可能会用掉太多内存，以致另一个程序失败，而使用户无从查找问题的真正根源。 此外，即使无害的内存泄漏也可能是其他问题的征兆。

内存泄漏会因为减少可用内存的数量从而降低计算机的性能。最终，在最糟糕的情况下，过多的可用内存被分配掉导致全部或部分设备停止正常工作，或者应用程序崩溃。内存泄漏可能不严重，甚至能够被常规的手段检测出来。在现代操作系统中，一个应用程序使用的常规内存在程序终止时被释放。这表示一个短暂运行的应用程序中的内存泄漏不会导致严重后果。

在以下情況，内存泄漏导致较严重的后果：

• 程序运行后置之不理，并且随着时间的流失消耗越来越多的内存（比如服务器上的后台任务，尤其是嵌入式系统中的后台任务，这些任务可能被运行后很多年内都置之不理）；
• 新的内存被频繁地分配，比如当显示电脑游戏或动画视频画面时；
• 程序能够请求未被释放的内存（比如共享内存），甚至是在程序终止的时候；
• 泄漏在操作系统内部发生；
• 泄漏在系统关键驱动中发生；
• 内存非常有限，比如在嵌入式系统或便携设备中；
• 当运行于一个终止时内存并不自动释放的操作系统（比如AmigaOS）之上，而且一旦丢失只能通过重启来恢复。

下面我们通过以下例子来介绍如何检测内存泄漏问题：

实际中不可能这么简单，如果这么简单也用不着别的方法，程序员一眼就可以看出问题，此程序只用于测试。

2、Windows平台下的内存泄漏检测

2.1、检测是否存在内存泄漏问题

Windows平台下面Visual Studio 调试器和 C 运行时 (CRT) 库为我们提供了检测和识别内存泄漏的有效方法，原理大致如下：内存分配要通过CRT在运行时实现，只要在分配内存和释放内存时分别做好记录，程序结束时对比分配内存和释放内存的记录就可以确定是不是有内存泄漏。在vs中启用内存检测的方法如下：

• STEP1，在程序中包括以下语句： （#include 语句必须采用上文所示顺序。 如果更改了顺序，所使用的函数可能无法正常工作。）

通过包括 crtdbg.h，将 malloc 和 free 函数映射到它们的调试版本，即 _malloc_dbg 和 _free_dbg，这两个函数将跟踪内存分配和释放。 此映射只在调试版本（在其中定义了_DEBUG）中发生。 发布版本使用普通的 malloc 和 free 函数。

#define 语句将 CRT 堆函数的基版本映射到对应的“Debug”版本。 并非绝对需要该语句；但如果没有该语句，内存泄漏转储包含的有用信息将较少。

• STEP2， 在添加了上述语句之后，可以通过在程序中包括以下语句（通常应恰好放在程序退出位置之前）来转储内存泄漏信息：

此时，完整的代码如下：

当在调试器下运行程序时，_CrtDumpMemoryLeaks 将在“输出”窗口中显示内存泄漏信息。 内存泄漏信息如下所示：

如果没有使用 #define _CRTDBG_MAP_ALLOC 语句，内存泄漏转储将如下所示：

未定义 _CRTDBG_MAP_ALLOC 时，所显示的会是：

• 内存分配编号（在大括号内）。

• 块类型（普通、客户端或 CRT）。

• “普通块”是由程序分配的普通内存。

• “客户端块”是由 MFC 程序用于需要析构函数的对象的特殊类型内存块。 MFC new 操作根据正在创建的对象的需要创建普通块或客户端块。

• “CRT 块”是由 CRT 库为自己使用而分配的内存块。 CRT 库处理这些块的释放，因此您不大可能在内存泄漏报告中看到这些块，除非出现严重错误（例如 CRT 库损坏）。

从不会在内存泄漏信息中看到下面两种块类型：

• “可用块”是已释放的内存块。

• “忽略块”是您已特别标记的块，因而不出现在内存泄漏报告中。

• 十六进制形式的内存位置。

• 以字节为单位的块大小。

• 前 16 字节的内容（亦为十六进制）。

定义了 _CRTDBG_MAP_ALLOC 时，还会显示在其中分配泄漏的内存的文件。 文件名后括号中的数字（本示例中为 10）是该文件中的行号。

注意：如果程序总是在同一位置退出，调用 _CrtDumpMemoryLeaks 将非常容易。 如果程序从多个位置退出，则无需在每个可能退出的位置放置对 _CrtDumpMemoryLeaks 的调用，而可以在程序开始处包含以下调用：

该语句在程序退出时自动调用 _CrtDumpMemoryLeaks。 必须同时设置 _CRTDBG_ALLOC_MEM_DF 和 _CRTDBG_LEAK_CHECK_DF 两个位域，如前面所示。

2.2、定位具体的内存泄漏地方

通过上面的方法，我们几乎可以定位到是哪个地方调用内存分配函数malloc和new等，如上例中的GetMemory函数中，即第10行！但是不能定位到，在哪个地方调用GetMemory()导致的内存泄漏，而且在大型项目中可能有很多处调用GetMemory。如何要定位到在哪个地方调用GetMemory导致的内存泄漏？

定位内存泄漏的另一种技术涉及在关键点对应用程序的内存状态拍快照。 CRT 库提供一种结构类型 _CrtMemState，您可用它存储内存状态的快照：

若要在给定点对内存状态拍快照，请向 _CrtMemCheckpoint 函数传递 _CrtMemState 结构。 该函数用当前内存状态的快照填充此结构：

通过向 _CrtMemDumpStatistics 函数传递 _CrtMemState 结构，可以在任意点转储该结构的内容：

若要确定代码中某一部分是否发生了内存泄漏，可以在该部分之前和之后对内存状态拍快照，然后使用 _CrtMemDifference 比较这两个状态：

顾名思义，_CrtMemDifference 比较两个内存状态（s1 和 s2），生成这两个状态之间差异的结果（s3）。 在程序的开始和结尾放置 _CrtMemCheckpoint 调用，并使用_CrtMemDifference 比较结果，是检查内存泄漏的另一种方法。 如果检测到泄漏，则可以使用 _CrtMemCheckpoint 调用通过二进制搜索技术来划分程序和定位泄漏。

如上面的例子程序我们可以这样来定位确切的调用GetMemory的地方：

调试时，程序输出如下结果：

这说明在s1和s2之间存在内存泄漏！！！如果GetMemory不是在s1和s2之间调用，那么就不会有信息输出。

3、Linux平台下的内存泄漏检测

在上面我们介绍了，vs中在代码中“包含crtdbg.h，将 malloc 和 free 函数映射到它们的调试版本，即 _malloc_dbg 和 _free_dbg，这两个函数将跟踪内存分配和释放。 此映射只在调试版本（在其中定义了_DEBUG）中发生。 发布版本使用普通的 malloc 和 free 函数。”即为malloc和free做了钩子，用于记录内存分配信息。

Linux下面也有原理相同的方法——mtrace，http://en.wikipedia.org/wiki/Mtrace。方法类似，我这就不具体描述，参加给出的链接。这节我主要介绍一个非常强大的工具valgrind。如下图所示：

如上图所示知道：

==6118== 100 bytes in 1 blocks are definitely lost in loss record 1 of 1
==6118==    at 0x4024F20: malloc (vg_replace_malloc.c:236)
==6118==    by 0x8048724: GetMemory(char*, int) (in /home/netsky/workspace/a.out)
==6118==    by 0x804874E: main (in /home/netsky/workspace/a.out)

是在main中调用了GetMemory导致的内存泄漏，GetMemory中是调用了malloc导致泄漏了100字节的内存。

Things to notice:
• There is a lot of information in each error message; read it carefully.
• The 6118 is the process ID; it’s usually unimportant.
• The first line ("Heap Summary") tells you what kind of error it is.
• Below the first line is a stack trace telling you where the problem occurred. Stack traces can get quite large, and be
confusing, especially if you are using the C++ STL. Reading them from the bottom up can help.

• The code addresses (eg. 0x4024F20) are usually unimportant, but occasionally crucial for tracking down weirder
bugs.

The stack trace tells you where the leaked memory was allocated. Memcheck cannot tell you why the memory leaked,
unfortunately. (Ignore the "vg_replace_malloc.c", that’s an implementation detail.)
There are several kinds of leaks; the two most important categories are:
• "definitely lost": your program is leaking memory -- fix it!
• "probably lost": your program is leaking memory, unless you’re doing funny things with pointers (such as moving
them to point to the middle of a heap block)

Valgrind的使用请见手册http://valgrind.org/docs/manual/manual.html。

4、总结

其实内存泄漏的原因可以概括为：调用了malloc/new等内存申请的操作，但缺少了对应的free/delete，总之就是，malloc/new比free/delete的数量多。我们在编程时需要注意这点，保证每个malloc都有对应的free，每个new都有对应的deleted！！！平时要养成这样一个好的习惯。

要避免内存泄漏可以总结为以下几点：

• 程序员要养成良好习惯，保证malloc/new和free/delete匹配；
• 检测内存泄漏的关键原理就是，检查malloc/new和free/delete是否匹配，一些工具也就是这个原理。要做到这点，就是利用宏或者钩子，在用户程序与运行库之间加了一层，用于记录内存分配情况。

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 */
＃i nclude

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

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)" 项下设置应用程序的默认标准库版本，这与命令行选项的效果是一样的。

终极解决办法：

在 Project/Setting/Link/General中的 Project Options: 加入 /FORCE:MULTIPLE即可。

转自http://hi.baidu.com/shitiansunny/blog/item/8de3368761204f2a67096e1c.html

最近在用 template 编写singleton模式代码的时候，遇到了一个问题，template要求实现要在同一个文件中，所以，我只能在h文件中定义并实现 singleton 模式类。类中必然要有静态成员变量，静态成员变量的定义成了问题，如果我放在cpp文件中，模板是不支持的，放在h文件中，如果h文件被多次包含，会出现重定义的情况。

    回来，请教高手，得知，可以在初始化静态成员变量前面加上__declspec(selectany) ，这样编译器会自动剔除对该静态成员的重复定义。

   最近半年也一直用WTL，ATL，COM等。其实在WTL，ATL中已经大量使用了__declspec(selectany)方法。我猜想这是为解决template单文件编程和静态成员变量在头文件中定义会出现重复定义矛盾而提出的。

总的来说：

    __declspec(selelctany) 使在头文件中定义静态成员变量可行。

===================================================================================

其他资料：

selectany使用在c/c++工程的连接期间，一般用得很少，所以很陌生。

这个属性告诉编译器声明的全局变量是一个"任一拣选"(pick-any)COMDAT.在连接时间，如果多个COMDAT定义能看到，连接器选择一个并且丢弃所有的剩余的。如果连接器选项/OPT:REF被选择，COMDAT中所有的没有引用的数据项被删除。

一个全局数据在EXE或者DLL中只能被初始化一次。当同一个头文件被多个源文件引用时，在头中定义全局数据始始化时，这个属性被使用。这个属性在c和c++的编译器中都是可用的。

COMDAT record
一个常用对象文件格式(COFF)记录,它包含的已被初始化的常用块数据和打包的函数对连接器是可以见的。
packaged function
当函数级的连接功能选择开关被打开时，一个函数能被编译器创建。在编译器产生的对象文件中COMDAT记录的打包的函数对于连接器是可见的。没有打包的函数只在对象级(the object level)上连接。

下面是MSDN上一些例子:

//Correct - x1 is initialized and externally visible

__declspec(selectany) int x1=1;

//Incorrect - const is by default static in C++, so

//x2 is not visible externally (This is OK in C, since

//const is not by default static in C)

const __declspec(selectany) int x2 =2;

//Correct - x3 is extern const, so externally visible

extern const __declspec(selectany) int x3=3;

//Correct - x4 is extern const, so it is externally visible

extern const int x4;

const __declspec(selectany) int x4=4;

//Incorrect - __declspec(selectany) is applied to the uninitialized

//declaration of x5

extern __declspec(selectany) int x5;

        microsoft的vc默认的是__cdecl方式，而windows API则是__stdcall，如果用vc开发dll给其他语言用，则应该指定__stdcall方式。堆栈由谁清除这个很重要，如果是要写汇编函数给C调用，一定要小心堆栈的清除工作，如果是__cdecl方式的函数，则函数本身（如果不用汇编写）则不需要关心保存参数的堆栈的清除，但是如果是__stdcall的规则，一定要在函数退出(ret)前恢复堆栈。
1.__cdecl
       所谓的C调用规则。按从右至左的顺序压参数入栈，由调用者把参数弹出栈。切记：对于传送参数的内存栈是由调用者来维护的。返回值在EAX中因此，对于象printf这样变参数的函数必须用这种规则。编译器在编译的时候对这种调用规则的函数生成修饰名的饿时候，仅在输出函数名前加上一个下划线前缀，格式为_functionname。
2.__stdcall
        按从右至左的顺序压参数入栈，由被调用者把参数弹出栈。_stdcall是Pascal程序的缺省调用方式，通常用于Win32 Api中，切记：函数自己在退出时清空堆栈，返回值在EAX中。　　__stdcall调用约定在输出函数名前加上一个下划线前缀，后面加上一个“@”符号和其参数的字节数，格式为_functionname@number。如函数int func(int a, double b)的修饰名是_func@12。
3.__fastcall
       __fastcall调用的主要特点就是快，因为它是通过寄存器来传送参数的（实际上，它用ECX和EDX传送前两个双字（DWORD）或更小的参数，剩下的参数仍旧自右向左压栈传送，被调用的函数在返回前清理传送参数的内存栈）。__fastcall调用约定在输出函数名前加上一个“@”符号，后面也是一个“@”符号和其参数的字节数，格式为@functionname@number。这个和__stdcall很象，唯一差别就是头两个参数通过寄存器传送。注意通过寄存器传送的两个参数是从左向右的，即第一个参数进ECX，第2个进EDX，其他参数是从右向左的入stack。返回仍然通过EAX.
4.__pascal
       这种规则从左向右传递参数，通过EAX返回，堆栈由被调用者清除

5.__thiscall

        仅仅应用于"C++"成员函数。this指针存放于CX寄存器，参数从右到左压。thiscall不是关键词，因此不能被程序员指定

       调用约定可以通过工程设置：Setting...\C/C++ \Code Generation项进行选择，缺省状态为__cdecl。

名字修饰约定：

1、修饰名(Decoration name)："C"或者"C++"函数在内部（编译和链接）通过修饰名识别
2、C编译时函数名修饰约定规则：
__stdcall调用约定在输出函数名前加上一个下划线前缀，后面加上一个"@"符号和其参数的字节数，格式为_functionname@number,例如 ：function(int a, int b)，其修饰名为：_function@8
__cdecl调用约定仅在输出函数名前加上一个下划线前缀，格式为_functionname。
__fastcall调用约定在输出函数名前加上一个"@"符号，后面也是一个"@"符号和其参数的字节数，格式为@functionname@number。

3、C++编译时函数名修饰约定规则：
__stdcall调用约定：
1)、以"?"标识函数名的开始，后跟函数名；
2)、函数名后面以"@@YG"标识参数表的开始，后跟参数表；
3)、参数表以代号表示：
X--void ，
D--char，
E--unsigned char，
F--short，
H--int，
I--unsigned int，
J--long，
K--unsigned long，
M--float，
N--double，
_N--bool，
PA--表示指针，后面的代号表明指针类型，如果相同类型的指针连续出现，以"0"代替，一个"0"代表一次重复；
4)、参数表的第一项为该函数的返回值类型，其后依次为参数的数据类型,指针标识在其所指数据类型前；
5)、参数表后以"@Z"标识整个名字的结束，如果该函数无参数，则以"Z"标识结束。
其格式为"?functionname@@YG*****@Z"或"?functionname@@YG*XZ"，例如
          int Test1(char *var1,unsigned long)-----“?Test1@@YGHPADK@Z”
          void Test2()                       -----“?Test2@@YGXXZ”

__cdecl调用约定：
规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的"@@YG"变为"@@YA"。
__fastcall调用约定：
规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的"@@YG"变为"@@YI"。
VC++对函数的省缺声明是"__cedcl",将只能被C/C++调用.

注意：
1、_beginthread需要__cdecl的线程函数地址，_beginthreadex和CreateThread需要__stdcall的线程函数地址。

2、一般WIN32的函数都是__stdcall。而且在Windef.h中有如下的定义：
#define CALLBACK __stdcall
#define WINAPI　 __stdcall

3、extern "C" _declspec(dllexport) int __cdecl Add(int a, int b);
   typedef int (__cdecl*FunPointer)(int a, int b);
   修饰符的书写顺序如上。

4、extern "C"的作用：如果Add(int a, int b)是在c语言编译器编译，而在c++文件使用，则需要在c++文件中声明：extern "C" Add(int a, int b)，因为c编译器和c++编译器对函数名的解释不一样（c++编译器解释函数名的时候要考虑函数参数，这样是了方便函数重载，而在c语言中不存在函数重载的问题），使用extern "C"，实质就是告诉c++编译器，该函数是c库里面的函数。如果不使用extern "C"则会出现链接错误。
一般象如下使用：
#ifdef _cplusplus
#define ETERN_C extern "C"
#else
#define EXTERN_C extern
#endif

#ifdef _cplusplus
extern "C"{
#endif
EXTERN_C int func(int a, int b);
#ifdef _cplusplus
}
#endif

5、MFC提供了一些宏，可以使用AFX_EXT_CLASS来代替__declspec(DLLexport)，并修饰类名，从而导出类，AFX_API_EXPORT来修饰函数，AFX_DATA_EXPORT来修饰变量
AFX_CLASS_IMPORT：__declspec(DLLexport)
AFX_API_IMPORT：__declspec(DLLexport)
AFX_DATA_IMPORT：__declspec(DLLexport)
AFX_CLASS_EXPORT：__declspec(DLLexport)
AFX_API_EXPORT：__declspec(DLLexport)
AFX_DATA_EXPORT：__declspec(DLLexport)
AFX_EXT_CLASS：#ifdef _AFXEXT
    AFX_CLASS_EXPORT
        #else
    AFX_CLASS_IMPORT

6、DLLMain负责初始化(Initialization)和结束(Termination)工作，每当一个新的进程或者该进程的新的线程访问DLL时，或者访问DLL的每一个进程或者线程不再使用DLL或者结束时，都会调用DLLMain。但是，使用TerminateProcess或TerminateThread结束进程或者线程，不会调用DLLMain。

7、一个DLL在内存中只有一个实例
DLL程序和调用其输出函数的程序的关系：
1)、DLL与进程、线程之间的关系
DLL模块被映射到调用它的进程的虚拟地址空间。
DLL使用的内存从调用进程的虚拟地址空间分配，只能被该进程的线程所访问。
DLL的句柄可以被调用进程使用；调用进程的句柄可以被DLL使用。
DLLDLL可以有自己的数据段，但没有自己的堆栈，使用调用进程的栈，与调用它的应用程序相同的堆栈模式。

2)、关于共享数据段
DLL定义的全局变量可以被调用进程访问；DLL可以访问调用进程的全局数据。使用同一DLL的每一个进程都有自己的DLL全局变量实例。如果多个线程并发访问同一变量，则需要使用同步机制；对一个DLL的变量，如果希望每个使用DLL的线程都有自己的值，则应该使用线程局部存储(TLS，Thread Local Strorage)。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/jia_xiaoxin/archive/2008/09/02/2868216.aspx

endl控制符的作用是将光标移动到输出设备中下一行开头处，并且清空缓冲区。
cout<<endl;
相当于
cout<<”\n” <<flush;

通过实例演示说明

1、文件操作演示全缓冲
创建一个控制台工程，输入如下代码：

#include <fstream>
using namespace std;
int main()
{
//创建文件test.txt并打开
ofstream outfile("test.txt");
//向test.txt文件中写入4096个字符’a’
for(int n=0;n<4096;n++)//经本人用VC6.0测试，作者说的是对的，但是在Dev-C++编译器中测试发现，将4096改为3000也会直接写入文件
{
outfile<<'a';
}
//暂停，按任意键继续
system("PAUSE");
//继续向test.txt文件中写入字符’b’，也就是说，第4097个字符是’b’
outfile<<'b';
//暂停，按任意键继续
system("PAUSE");
return 0;
}

上面这段代码很容易理解，已经在代码内部作了注释。
编写这段小代码的目的是验证WindowsXP下全缓冲的大小是4096个字节，并验证缓冲区满后会刷新缓冲区，执行真正的I/O操作。

编译并执行，运行结果如下：

此时打开工程所在文件夹下的test.txt文件，您会发现该文件是空的，这说明4096个字符“a”还在缓冲区，并没有真正执行I/O操作。敲一下回车键，窗口变为如下：

此时再打开test.txt文件，您就会发下该文件中已经有了4096个字符“a”。这说明全缓冲区的大小是4K（4096），缓冲区满后执行了I/O操作，而字符“b”还在缓冲区。
再次敲一下回车键，窗口变为如下：

此时再打开test.txt文件，您就会发现字符“b”也在其中了。这一步验证了文件关闭时刷新了缓冲区。

2、键盘操作演示行缓冲
先介绍getchar()函数。
函数原型：int getchar(void);
说明：当程序调用getchar()函数时，程序就等着用户按键，用户输入的字符被存放在键盘缓冲区中，直到用户按回车为止（回车字符也放在缓冲区中）。当用户键入回车之后，getchar()函数才开始从键盘缓冲区中每次读入一个字符。也就是说，后续的getchar()函数调用不会等待用户按键，而直接读取缓冲区中的字符，直到缓冲区中的字符读完后，才重新等待用户按键。
不知道您明白了没有，再通俗一点讲，当程序调用getchar()函数时，程序就等着用户按键，并等用户按下回车键返回。期间按下的字符存放在缓冲区，第一个字符作为函数返回值。继续调用getchar()函数，将不再等用户按键，而是返回您刚才输入的第2个字符；继续调用，返回第3个字符，直到缓冲区中的字符读完后，才等待用户按键。
如果您还没有明白，只能怨我表达能力有限，您可以结合以下实例体会。

创建一个控制台工程，输入如下代码：

#include <iostream>
using namespace std;
int main()
{
char c;
//第一次调用getchar()函数
//程序执行时，您可以输入一串字符并按下回车键，按下回车键后该函数才返回
c=getchar();
//显示getchar()函数的返回值
cout<<c<<endl;
//暂停
system("PAUSE");
//循环多次调用getchar()函数
//将每次调用getchar()函数的返回值显示出来
//直到遇到回车符才结束
while((c=getchar())!='\n')
{
printf("%c",c);
}
//暂停
system("PAUSE");
return 0;
}

这段小代码也很简单，同样在代码内部都有注释。
getchar()函数的执行就是采用了行缓冲。第一次调用getchar()函数，会让程序使用者（用户）输入一行字符并直至按下回车键 函数才返回。此时用户输入的字符和回车符都存放在行缓冲区。
再次调用getchar()函数，会逐步输出行缓冲区的内容。
好了，本人表达能力有限，还是编译运行程序，通过运行结果自己领会吧。

编译运行程序，会提示您输入字符，您可以交替按下一些字符，如下：

您一直按下去，您就会发现当您按到第4094个字符时，不允许您继续输入字符。这说明行缓冲区的大小也是4K。
此时您按下回车键，返回第一个字符’a’，如下图：

继续敲一下回车键，将缓冲区的其它的字符全部输出，如下图：

3、标准错误输出不带缓冲
如错误输出时使用：

cerr<<”错误，请检查输入的参数!”;

这条语句等效于：
fprintf(stderr, ”错误，请检查输入的参数!”);

好了，就说到这吧，祝您好运，希望能对您有所帮助。

       需要一个数据对象为整个类而非某个对象服务,同时又力求不破坏类的封装性,即要求此成员隐藏在类的内部，对外不可见。

       static的内部机制：
       静态数据成员要在程序一开始运行时就必须存在。因为函数在程序运行中被调用，所以静态数据成员不能在任何函数内分配空间和初始化。
       这样，它的空间分配有三个可能的地方，一是作为类的外部接口的头文件，那里有类声明；二是类定义的内部实现，那里有类的成员函数定义；三是应用程序的main（）函数前的全局数据声明和定义处。
      静态数据成员要实际地分配空间，故不能在类的声明中定义（只能声明数据成员）。类声明只声明一个类的“尺寸和规格”，并不进行实际的内存分配，所以在类声 明中写成定义是错误的。它也不能在头文件中类声明的外部定义，因为那会造成在多个使用该类的源文件中，对其重复定义。
      static被引入以告知编译器，将变量存储在程序的静态存储区而非栈上空间，静态
数据成员按定义出现的先后顺序依次初始化，注意静态成员嵌套时，要保证所嵌套的成员已经初始化了。消除时的顺序是初始化的反顺序。

       static的优势：
       可以节省内存，因为它是所有对象所公有的，因此，对多个对象来说，静态数据成员只存储一处，供所有对象共用。静态数据成员的值对每个对象都是一样，但它的 值是可以更新的。只要对静态数据成员的值更新一次，保证所有对象存取更新后的相同的值，这样可以提高时间效率。

        引用静态数据成员时，采用如下格式：
         <类名>::<静态成员名>
    如果静态数据成员的访问权限允许的话(即public的成员)，可在程序中，按上述格式
来引用静态数据成员。

       PS:
      (1)类的静态成员函数是属于整个类而非类的对象，所以它没有this指针，这就导致
了它仅能访问类的静态数据和静态成员函数。
      (2)不能将静态成员函数定义为虚函数。
      (3)由于静态成员声明于类中，操作于其外，所以对其取地址操作，就多少有些特殊
，变量地址是指向其数据类型的指针 ，函数地址类型是一个“nonmember函数指针”。

      (4)由于静态成员函数没有this指针，所以就差不多等同于nonmember函数，结果就
产生了一个意想不到的好处：成为一个callback函数，使得我们得以将C++和C-based X W
indow系统结合，同时也成功的应用于线程函数身上。
      (5)static并没有增加程序的时空开销，相反她还缩短了子类对父类静态成员的访问
时间，节省了子类的内存空间。
      (6)静态数据成员在<定义或说明>时前面加关键字static。
      (7)静态数据成员是静态存储的，所以必须对它进行初始化。
      (8)静态成员初始化与一般数据成员初始化不同:
      初始化在类体外进行，而前面不加static，以免与一般静态变量或对象相混淆；
      初始化时不加该成员的访问权限控制符private，public等；
           初始化时使用作用域运算符来标明它所属类；
           所以我们得出静态数据成员初始化的格式：
         <数据类型><类名>::<静态数据成员名>=<值>
      (9)为了防止父类的影响，可以在子类定义一个与父类相同的静态变量，以屏蔽父类的影响。这里有一点需要注意：我们说静态成员为父类和子类共享，但我们有 重复定义了静态成员，这会不会引起错误呢？不会，我们的编译器采用了一种绝妙的手法：name-mangling 用以生成唯一的标志。

二、例子程序
这是一个前辈写的，非常详细
//main.cpp
int a = 0; 全局初始化区
char *p1; 全局未初始化区
main()
{
int b; 栈
char s[] = "abc"; 栈
char *p2; 栈
char *p3 = "123456"; 123456在常量区，p3在栈上。
static int c =0； 全局（静态）初始化区
p1 = (char *)malloc(10);
p2 = (char *)malloc(20);
分配得来得10和20字节的区域就在堆区。
strcpy(p1, "123456"); 123456放在常量区，编译器可能会将它与p3所指向的"123456"优化成一个地方。
}

二、堆和栈的理论知识
2.1申请方式
stack:
由系统自动分配。 例如，声明在函数中一个局部变量 int b; 系统自动在栈中为b开辟空间
heap:
需要程序员自己申请，并指明大小，在c中malloc函数
如p1 = (char *)malloc(10);
在C++中用new运算符
如p2 = (char *)malloc(10);
但是注意p1、p2本身是在栈中的。

2.2
申请后系统的响应
栈：只要栈的剩余空间大于所申请空间，系统将为程序提供内存，否则将报异常提示栈溢出。
堆：首先应该知道操作系统有一个记录空闲内存地址的链表，当系统收到程序的申请时，
会遍历该链表，寻找第一个空间大于所申请空间的堆结点，然后将该结点从空闲结点链表中删除，并将该结点的空间分配给程序，另外，对于大多数系统，会在这块内存空间中的首地址处记录本次分配的大小，这样，代码中的delete语句才能正确的释放本内存空间。另外，由于找到的堆结点的大小不一定正好等于申请的大小，系统会自动的将多余的那部分重新放入空闲链表中。

2.3申请大小的限制
栈：在Windows下,栈是向低地址扩展的数据结构，是一块连续的内存的区域。这句话的意思是栈顶的地址和栈的最大容量是系统预先规定好的，在 WINDOWS下，栈的大小是2M（也有的说是1M，总之是一个编译时就确定的常数），如果申请的空间超过栈的剩余空间时，将提示overflow。因此，能从栈获得的空间较小。
堆：堆是向高地址扩展的数据结构，是不连续的内存区域。这是由于系统是用链表来存储的空闲内存地址的，自然是不连续的，而链表的遍历方向是由低地址向高地址。堆的大小受限于计算机系统中有效的虚拟内存。由此可见，堆获得的空间比较灵活，也比较大。

2.4申请效率的比较：
栈由系统自动分配，速度较快。但程序员是无法控制的。
堆是由new分配的内存，一般速度比较慢，而且容易产生内存碎片,不过用起来最方便.
另外，在WINDOWS下，最好的方式是用VirtualAlloc分配内存，他不是在堆，也不是在栈是直接在进程的地址空间中保留一快内存，虽然用起来最不方便。但是速度快，也最灵活。

2.5堆和栈中的存储内容
栈： 在函数调用时，第一个进栈的是主函数中后的下一条指令（函数调用语句的下一条可执行语句）的地址，然后是函数的各个参数，在大多数的C编译器中，参数是由右往左入栈的，然后是函数中的局部变量。注意静态变量是不入栈的。
当本次函数调用结束后，局部变量先出栈，然后是参数，最后栈顶指针指向最开始存的地址，也就是主函数中的下一条指令，程序由该点继续运行。
堆：一般是在堆的头部用一个字节存放堆的大小。堆中的具体内容有程序员安排。

2.6存取效率的比较

char s1[] = "aaaaaaaaaaaaaaa";
char *s2 = "bbbbbbbbbbbbbbbbb";
aaaaaaaaaaa是在运行时刻赋值的；
而bbbbbbbbbbb是在编译时就确定的；
但是，在以后的存取中，在栈上的数组比指针所指向的字符串(例如堆)快。
比如：
#include
void main()
{
char a = 1;
char c[] = "1234567890";
char *p ="1234567890";
a = c[1];
a = p[1];
return;
}
对应的汇编代码
10: a = c[1];
00401067 8A 4D F1 mov cl,byte ptr [ebp-0Fh]
0040106A 88 4D FC mov byte ptr [ebp-4],cl
11: a = p[1];
0040106D 8B 55 EC mov edx,dword ptr [ebp-14h]
00401070 8A 42 01 mov al,byte ptr [edx+1]
00401073 88 45 FC mov byte ptr [ebp-4],al
第一种在读取时直接就把字符串中的元素读到寄存器cl中，而第二种则要先把指针值读到edx中，在根据edx读取字符，显然慢了。

2.7小结：
堆和栈的区别可以用如下的比喻来看出：
使用栈就象我们去饭馆里吃饭，只管点菜（发出申请）、付钱、和吃（使用），吃饱了就走，不必理会切菜、洗菜等准备工作和洗碗、刷锅等扫尾工作，他的好处是快捷，但是自由度小。
使用堆就象是自己动手做喜欢吃的菜肴，比较麻烦，但是比较符合自己的口味，而且自由度大。

1、内存分配方面：

    堆：一般由程序员分配释放， 若程序员不释放，程序结束时可能由OS回收 。注意它与数据结构中的堆是两回事，分配方式是类似于链表。可能用到的关键字如下：new、malloc、delete、free等等。

    栈：由编译器(Compiler)自动分配释放，存放函数的参数值，局部变量的值等。其操作方式类似于数据结构中的栈。

2、申请方式方面：

    堆：需要程序员自己申请，并指明大小。在c中malloc函数如p1 = (char *)malloc(10)；在C++中用new运算符，但是注意p1、p2本身是在栈中的。因为他们还是可以认为是局部变量。

    栈：由系统自动分配。 例如，声明在函数中一个局部变量 int b；系统自动在栈中为b开辟空间。

3、系统响应方面：

    堆：操作系统有一个记录空闲内存地址的链表，当系统收到程序的申请时，会遍历该链表，寻找第一个空间大于所申请空间的堆结点，然后将该结点从空闲结点链表中删除，并将该结点的空间分配给程序，另外，对于大多数系统，会在这块内存空间中的首地址处记录本次分配的大小，这样代码中的delete语句才能正确的释放本内存空间。另外由于找到的堆结点的大小不一定正好等于申请的大小，系统会自动的将多余的那部分重新放入空闲链表中。

    栈：只要栈的剩余空间大于所申请空间，系统将为程序提供内存，否则将报异常提示栈溢出。

4、大小限制方面：

    堆：是向高地址扩展的数据结构，是不连续的内存区域。这是由于系统是用链表来存储的空闲内存地址的，自然是不连续的，而链表的遍历方向是由低地址向高地址。堆的大小受限于计算机系统中有效的虚拟内存。由此可见，堆获得的空间比较灵活，也比较大。

    栈：在Windows下, 栈是向低地址扩展的数据结构，是一块连续的内存的区域。这句话的意思是栈顶的地址和栈的最大容量是系统预先规定好的，在WINDOWS下，栈的大小是固定的（是一个编译时就确定的常数），如果申请的空间超过栈的剩余空间时，将提示overflow。因此，能从栈获得的空间较小。

5、效率方面：

    堆：是由new分配的内存，一般速度比较慢，而且容易产生内存碎片，不过用起来最方便，另外，在WINDOWS下，最好的方式是用VirtualAlloc分配内存，他不是在堆，也不是在栈是直接在进程的地址空间中保留一快内存，虽然用起来最不方便。但是速度快，也最灵活。

    栈：由系统自动分配，速度较快。但程序员是无法控制的。

6、存放内容方面：

    堆：一般是在堆的头部用一个字节存放堆的大小。堆中的具体内容有程序员安排。

    栈：在函数调用时第一个进栈的是主函数中后的下一条指令（函数调用语句的下一条可执行语句）的地址然后是函数的各个参数，在大多数的C编译器中，参数是由右往左入栈，然后是函数中的局部变量。 注意: 静态变量是不入栈的。当本次函数调用结束后，局部变量先出栈，然后是参数，最后栈顶指针指向最开始存的地址，也就是主函数中的下一条指令，程序由该点继续运行。

7、存取效率方面：

    堆：char *s1 = "Hellow Word"；是在编译时就确定的；

    栈：char s1[] = "Hellow Word"； 是在运行时赋值的；用数组比用指针速度要快一些，因为指针在底层汇编中需要用edx寄存器中转一下，而数组在栈上直接读取。

　　下面是对C++的虚函数这玩意儿的理解。

　　一， 什么是虚函数（如果不知道虚函数为何物，但有急切的想知道，那你就应该从这里开始）

　　简单地说，那些被virtual关键字修饰的成员函数，就是虚函数。虚函数的作用，用专业术语来解释就是实现多态性（Polymorphism），多态性是将接口与实现进行分离；用形象的语言来解释就是实现以共同的方法，但因个体差异而采用不同的策略。下面来看一段简单的代码

　　class A{

　　public:

　　void print(){ cout<<”This is A”<<endl;}

　　};

　　class B:public A{

　　public:

　　void print(){ cout<<”This is B”<<endl;}

　　};

　　int main(){ //为了在以后便于区分，我这段main()代码叫做main1

　　A a;

　　B b;

　　a.print();

　　b.print();

　　}

　　通过class A和class B的print()这个接口，可以看出这两个class因个体的差异而采用了不同的策略，输出的结果也是我们预料中的，分别是This is A和This is B。但这是否真正做到了多态性呢？No，多态还有个关键之处就是一切用指向基类的指针或引用来操作对象。那现在就把main()处的代码改一改。

　　int main(){ //main2

　　A a;

　　B b;

　　A* p1=&a;

　　A* p2=&b;

　　p1->print();

　　p2->print();

　　}

　　运行一下看看结果，哟呵，蓦然回首，结果却是两个This is A。问题来了，p2明明指向的是class B的对象但却是调用的class A的print()函数，这不是我们所期望的结果，那么解决这个问题就需要用到虚函数

　　class A{

　　public:

　　virtual void print(){ cout<<”This is A”<<endl;} //现在成了虚函数了

　　};

　　class B:public A{

　　public:

　　void print(){ cout<<”This is B”<<endl;} //这里需要在前面加上关键字virtual吗？

　　};

　　毫无疑问，class A的成员函数print()已经成了虚函数，那么class B的print()成了虚函数了吗？回答是Yes，我们只需在把基类的成员函数设为virtual，其派生类的相应的函数也会自动变为虚函数。所以，class B的print()也成了虚函数。那么对于在派生类的相应函数前是否需要用virtual关键字修饰，那就是你自己的问题了。

　　现在重新运行main2的代码，这样输出的结果就是This is A和This is B了。

　　现在来消化一下，我作个简单的总结，指向基类的指针在操作它的多态类对象时，会根据不同的类对象，调用其相应的函数，这个函数就是虚函数。

　　二， 虚函数是如何做到的（如果你没有看过《Inside The C++ Object Model》这本书，但又急切想知道，那你就应该从这里开始）

　　虚函数是如何做到因对象的不同而调用其相应的函数的呢？现在我们就来剖析虚函数。我们先定义两个类

　　class A{ //虚函数示例代码

　　public:

　　virtual void fun(){cout<<1<<endl;}

　　virtual void fun2(){cout<<2<<endl;}

　　};

　　class B:public A{

　　public:

　　void fun(){cout<<3<<endl;}

　　void fun2(){cout<<4<<endl;}

　　};

　　由于这两个类中有虚函数存在，所以编译器就会为他们两个分别插入一段你不知道的数据，并为他们分别创建一个表。那段数据叫做vptr指针，指向那个表。那个表叫做vtbl，每个类都有自己的vtbl，vtbl的作用就是保存自己类中虚函数的地址，我们可以把vtbl形象地看成一个数组，这个数组的每个元素存放的就是虚函数的地址，请看图

　　通过上图，可以看到这两个vtbl分别为class A和class B服务。现在有了这个模型之后，我们来分析下面的代码

　　A *p=new A;

　　p->fun();

　　毫无疑问，调用了A::fun()，但是A::fun()是如何被调用的呢？它像普通函数那样直接跳转到函数的代码处吗？No，其实是这样的，首先是取出vptr的值，这个值就是vtbl的地址，再根据这个值来到vtbl这里，由于调用的函数A::fun()是第一个虚函数，所以取出vtbl第一个slot里的值，这个值就是A::fun()的地址了，最后调用这个函数。现在我们可以看出来了，只要vptr不同，指向的vtbl就不同，而不同的vtbl里装着对应类的虚函数地址，所以这样虚函数就可以完成它的任务。

　　而对于class A和class B来说，他们的vptr指针存放在何处呢？其实这个指针就放在他们各自的实例对象里。由于class A和class B都没有数据成员，所以他们的实例对象里就只有一个vptr指针。通过上面的分析，现在我们来实作一段代码，来描述这个带有虚函数的类的简单模型。

　　#include<iostream>

　　using namespace std;

　　//将上面“虚函数示例代码”添加在这里

　　int main(){

　　void (*fun)(A*);

　　A *p=new B;

　　long lVptrAddr;

　　memcpy(&lVptrAddr,p,4);

　　memcpy(&fun,reinterpret_cast<long*>(lVptrAddr),4);

　　fun(p);

　　delete p;

　　system("pause");

　　}

　　用VC或Dev-C++编译运行一下，看看结果是不是输出3，如果不是，那么太阳明天肯定是从西边出来。现在一步一步开始分析

　　void (*fun)(A*); 这段定义了一个函数指针名字叫做fun，而且有一个A*类型的参数，这个函数指针待会儿用来保存从vtbl里取出的函数地址

　　A* p=new B; new B是向内存(内存分5个区:全局名字空间,自由存储区,寄存器,代码空间,栈)自由存储区申请一个内存单元的地址然后隐式地保存在一个指针中.然后把这个地址附值给A类型的指针P.

　　.

　　long lVptrAddr; 这个long类型的变量待会儿用来保存vptr的值

　　memcpy(&lVptrAddr,p,4); 前面说了，他们的实例对象里只有vptr指针，所以我们就放心大胆地把p所指的4bytes内存里的东西复制到lVptrAddr中，所以复制出来的4bytes内容就是vptr的值，即vtbl的地址

　　现在有了vtbl的地址了，那么我们现在就取出vtbl第一个slot里的内容

　　memcpy(&fun,reinterpret_cast<long*>(lVptrAddr),4); 取出vtbl第一个slot里的内容，并存放在函数指针fun里。需要注意的是lVptrAddr里面是vtbl的地址，但lVptrAddr不是指针，所以我们要把它先转变成指针类型

　　fun(p); 这里就调用了刚才取出的函数地址里的函数，也就是调用了B::fun()这个函数，也许你发现了为什么会有参数p,其实类成员函数调用时，会有个this指针，这个p就是那个this指针，只是在一般的调用中编译器自动帮你处理了而已，而在这里则需要自己处理。

　　delete p; 释放由p指向的自由空间;

　　system("pause"); 屏幕暂停;

　　如果调用B::fun2()怎么办？那就取出vtbl的第二个slot里的值就行了

　　memcpy(&fun,reinterpret_cast<long*>(lVptrAddr+4),4); 为什么是加4呢？因为一个指针的长度是4bytes，所以加4。或者memcpy(&fun,reinterpret_cast<long*>(lVptrAddr)+1,4); 这更符合数组的用法，因为lVptrAddr被转成了long*型别，所以+1就是往后移sizeof(long)的长度

　　三， 以一段代码开始

　　#include<iostream>

　　using namespace std;

　　class A{ //虚函数示例代码2

　　public:

　　virtual void fun(){ cout<<"A::fun"<<endl;}

　　virtual void fun2(){cout<<"A::fun2"<<endl;}

　　};

　　class B:public A{

　　public:

　　void fun(){ cout<<"B::fun"<<endl;}

　　void fun2(){ cout<<"B::fun2"<<endl;}

　　}; //end//虚函数示例代码2

　　int main(){

　　void (A::*fun)(); //定义一个函数指针

　　A *p=new B;

　　fun=&A::fun;

　　(p->*fun)();

　　fun = &A::fun2;

　　(p->*fun)();

　　delete p;

　　system("pause");

　　}

　　你能估算出输出结果吗？如果你估算出的结果是A::fun和A::fun2，呵呵，恭喜恭喜，你中圈套了。其实真正的结果是B::fun和B::fun2，如果你想不通就接着往下看。给个提示，&A::fun和&A::fun2是真正获得了虚函数的地址吗？

　　首先我们回到第二部分，通过段实作代码，得到一个“通用”的获得虚函数地址的方法

　　#include<iostream>

　　using namespace std;

　　//将上面“虚函数示例代码2”添加在这里

　　void CallVirtualFun(void* pThis,int index=0){

　　void (*funptr)(void*);

　　long lVptrAddr;

　　memcpy(&lVptrAddr,pThis,4);

　　memcpy(&funptr,reinterpret_cast<long*>(lVptrAddr)+index,4);

　　funptr(pThis); //调用

　　}

　　int main(){

　　A* p=new B;

　　CallVirtualFun(p); //调用虚函数p->fun()

　　CallVirtualFun(p,1);//调用虚函数p->fun2()

　　system("pause");

　　}

　　现在我们拥有一个“通用”的CallVirtualFun方法。

　　这个通用方法和第三部分开始处的代码有何联系呢？联系很大。由于A::fun()和A::fun2()是虚函数，所以&A::fun和&A::fun2获得的不是函数的地址，而是一段间接获得虚函数地址的一段代码的地址，我们形象地把这段代码看作那段CallVirtualFun。编译器在编译时，会提供类似于CallVirtualFun这样的代码，当你调用虚函数时，其实就是先调用的那段类似CallVirtualFun的代码，通过这段代码，获得虚函数地址后，最后调用虚函数，这样就真正保证了多态性。同时大家都说虚函数的效率低，其原因就是，在调用虚函数之前，还调用了获得虚函数地址的代码。

　　最后的说明：本文的代码可以用VC6和Dev-C++4.9.8.0通过编译，且运行无问题。其他的编译器小弟不敢保证。其中，里面的类比方法只能看成模型，因为不同的编译器的低层实现是不同的。例如this指针，Dev-C++的gcc就是通过压栈，当作参数传递，而VC的编译器则通过取出地址保存在ecx中。所以这些类比方法不能当作具体实现

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/hujiangnet/archive/2008/11/01/3201746.aspx

(0)前言

  #Pragma 指令的作用是设定编译器的状态或者是指示编译器完成一些特定的动作。#pragma 指令对每个编译器给出了一个方法,在保持与C和C++语言完全兼容的情况下,给出主机或操作系统专有的特征。依据定义,编译指示是机器或操作系统专有的,且对于每个编译器都是不同的。  
   其格式一般为:   #Pragma   Para  
  其中Para为参数，下面来看一些常用的参数。  

(1) #Pragma message参数能够在编译信息输出窗口中输出相应的信息

       这对于源代码信息的控制是非常重要的。其使用方法为： Pragma   message(“消息文本”)   
       当我们在程序中定义了许多宏来控制源代码版本的时候，我们自己有可能都会忘记有没有正确的设置这些宏，此时我们可以用这条指令在编译的时候就进行检查。假设我们希望判断自己有没有在源代码的什么地方定义了_X86这个宏可以用下面的方法  
            #ifdef   _X86  
            #pragma message(“_X86 macro activated!”)  
            #endif  
       若定义了_X86，程序编译时就会在显示“_X86 macro activated!”。我们就不会因为不记得自己定义的一些特定的宏而抓耳挠腮了 。  

(2) #pragma code_seg能够设置程序中函数代码存放的代码段,

     开发驱动程序的时候就会使用到它。格式如下：  
         #pragma code_seg( [ [ { push | pop}, ] [ identifier, ] ][ "segment-name" [, "segment-class" ] ])
     该指令用来指定函数在.obj文件中存放的节,观察OBJ文件可以使用VC自带的dumpbin命令行程序 ,如果code_seg没有带参数的话,则函数在OBJ文件中存放在默认在.text节中。
    push (可选参数) 将一个记录放到内部编译器的堆栈中,可选参数可以为一个标识符或者节名
    pop(可选参数) 将一个记录从堆栈顶端弹出,该记录可以为一个标识符或者节名
    identifier (可选参数) 当使用push指令时,为压入堆栈的记录指派的一个标识符,当该标识符被删除的时候和其相关的堆栈中的记录将被弹出堆栈
    "segment-name" (可选参数) 表示函数存放的节名
例如:
            //默认情况下,函数被存放在.text节中
            void func1() {                  // stored in .text
                              }
            //将函数存放在.my_data1节中
            #pragma code_seg(".my_data1")
            void func2() {                  // stored in my_data1
                              }
            //r1为标识符,将函数放入.my_data2节中
             #pragma code_seg(push, r1, ".my_data2")
             void func3() {                  // stored in my_data2
                               }
              int main() {}

 (3)#pragma  once (比较常用)若用在头文件的最开始处就能够保证头文件被编译一次.

      一般在整个工程中我们只要包含头文件一次就够了，若多个.c/.cpp 文件中都要包含同一个头文件，比如 Windows.h，那很多声明等等岂不是有两次了？解决这个问题的传统的方法是在头文件开始出用 #define 定义一个宏，比如 Windows.h 中:  
              #ifndef   _WINDOWS_  
              #define   _WINDOWS_  
              #endif
      这样就可以避免被包含多次。但是这样的后果是代码的可读性较差 (个人观点)，VC给我们提供了另外一个途径，那就是在文件的前面加上:  
               #pragma   once”  

   
(4)#pragma  hdrstop表示预编译头文件到此为止

       后面的头文件不进行预编译。BCB可以预编译头文件以加快链接的速度，但如果所有头文件都进行预编译又可能占太多磁盘空间，所以使用这个选项排除一些头文件.有时单元之间有依赖关系，比如单元A依赖单元B，所以单元B要先于单元A编译。你可以用#pragma   startup指定编译优先级，如果使用了#pragma   package(smart_init) ，BCB就会根据优先级的大小先后编译。  

 
（5）#pragma  resource "*.dfm"表示把*.dfm文件中的资源加入工程。*.dfm中包括窗体外观的定义。  

（6） #pragma warning允许有选择性的修改编译器的警告消息的行为

指令格式如下:
                #pragma warning( warning-specifier : warning-number-list [;warning-specifier :  warning-  number-list...])
                #pragma warning( push[ ,n ] )
                #pragma warning( pop )
主要用到的警告表示有如下几个:
                once:只显示一次(警告/错误等)消息
                default:重置编译器的警告行为到默认状态
                1,2,3,4:四个警告级别
                disable:禁止指定的警告信息
                error:将指定的警告信息作为错误报告
                 #pragma   warning( disable: 4507  34; once : 4385; error : 164   )  
  等价于：  
                 #pragma   warning(disable:4507   34)   //  不显示4507和34号警告信息  
                 #pragma   warning(once:4385)   //   4385号警告信息仅报告一次  
                 #pragma   warning(error:164)   //   把164号警告信息作为一个错误。  
                 #pragma   warning( push )保存所有警告信息的现有的警告状态。  
                 #pragma   warning( push,n)保存所有警告信息的现有的警告状态，并且把全局警告等级设定为n。  
                 #pragma   warning( pop )向栈中弹出最后一个警告信息，在入栈和出栈之间所作的一切改动取消。例如：  
                 #pragma   warning(   push   )  
                 #pragma   warning(   disable   :   4705   )  
                 #pragma   warning(   disable   :   4706   )  
                 #pragma   warning(   disable   :   4707   )  
                 //.......  
                 #pragma   warning(   pop   )  
      在这段代码的最后，重新保存所有的警告信息(包括4705，4706和4707)。  
   

（7）pragma   comment将一个注释记录放入一个对象文件或可执行文件中

该指令的格式为

 #pragma comment( "comment-type" [, commentstring] )
                 comment-type(注释类型):可以指定为五种预定义的标识符的其中一种，五种预定义的标识符为:
           compiler:将编译器的版本号和名称放入目标文件中,本条注释记录将被编译器忽略，如果你为该记录类型提供了commentstring参数,编译器将会产生一个警告
           例如:#pragma comment( compiler )
           exestr: 链接时，将commentstring参数放入到可执行文件中,当操作系统加载可执行文件的时候,该参数字符串不会被加载到内存中.但是,该字符串可被dumpbin之类的程序查找出并打印出来,你可以用这个标识符将版本号码之类的信息嵌入到可执行文件中!
            lib:用来将一个库文件链接到目标文件中
比如我们连接的时候用到了WSock32.lib，你当然可以不辞辛苦地把它加入到你的工程中。但是我觉得更方便的方法是使用#pragma指示符，指定要连接的库:  
                                    #pragma   comment(lib,   "WSock32.lib")
              linker:将一个链接选项放入目标文件中,你可以使用这个指令来代替由命令行传入的或者在开发环境中设置的链接选项,你可以指定/include选项来强制包含某个对象,例如:
                                     #pragma comment(linker, "/include:__mySymbol")
你可以在程序中设置下列链接选项
                                    /DEFAULTLIB
                                    /EXPORT
                                    /INCLUDE
                                    /MERGE
                                    / SECTION
   这些选项在这里就不一一说明了,详细信息请看msdn!
             user:将一般的注释信息放入目标文件中commentstring参数包含注释的文本信息,这个注释记录将被链接器忽略，例如:
                                   #pragma comment( user, "Compiled on " __DATE__ " at " __TIME__ )

 
（8）#pragma data_seg建立一个新的数据段并定义共享数据

格式为：
             #pragma data_seg （"shareddata"）
             HWND sharedwnd=NULL;//共享数据
              #pragma data_seg()

应用1：在DLL中定义一个共享的，有名字的数据段。
       注意：a、这个数据段中的全局变量能够被多个进程共享。否则多个进程之间无法共享DLL中的全局变量。
       b、共享数据必须初始化，否则微软编译器会把没有初始化的数据放到.BSS段中，从而导致多个进程之间的共享行为失败。
     假如在一个DLL中这么写：
                 #pragma data_seg("MyData")
                 int g_Value; // 全局变量未初始化
                 #pragma data_seg()
      DLL提供两个接口函数：
                 int GetValue()
                         {
                          return g_Value;
                          }
                  void SetValue(int n)
                          {
                          g_Value = n;
                          }
          然后启动两个都调用了这个DLL的进程A和B，假如A调用了SetValue(5); B接着调用int m = GetValue(); 那么m的值不一定是5，而是个未定义的值。因为DLL中的全局数据对于每一个调用他的进程而言，是私有的，不能共享的。假如您对g_Value进行了初始化，那么g_Value就一定会被放进MyData段中。

换句话说，假如A调用了SetValue(5); B接着调用int m = GetValue(); 那么m的值就一定是5！这就实现了跨进程之间的数据通信！#pragma

应用2： data_seg控制应用程序的启动次数
        有的时候我们可能想让一个应用程序只启动一次，就像单件模式(singleton)一样，实现的方法可能有多种，这里说说用#pragma data_seg来实现的方法，很是简洁便利。应用程序的入口文件前面加上：
              #pragma data_seg("flag_data")
              int app_count = 0;
               #pragma data_seg()
              #pragma comment(linker,"/SECTION:flag_data,RWS")
    然后程序启动的地方加上
               if(app_count>0)    // 如果计数大于0，则退出应用程序。
                             {
                             //MessageBox(NULL, "已经启动一个应用程序", "Warning", MB_OK);
                             //printf("no%d application", app_count);
                             return FALSE;
                              }
               app_count++;

（9）其他用法

    编译程序可以用#pragma指令激活或终止该编译程序支持的一些编译功能。例如，对循环优化功能：
                 #pragma loop_opt(on)         // 激活
                 #pragma loop_opt(off)       // 终止
      有时，程序中会有些函数会使编译器发出你熟知而想忽略的警告，如   “Parameter xxx is never used in function xxx”，可以这样：
                 #pragma warn —100         // Turn off the warning message for warning #100
                 int insert_record(REC *r)
                  { /* function body */ }
                  #pragma warn +100        // Turn the warning message for warning #100 back on
      函数会产生一条有唯一特征码100的警告信息，如此可暂时终止该警告。 每个编译器对#pragma的实现不同，在一个编译器中有效在别的编译器中几乎无效。可从编译器的文档中查看。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/gueter/archive/2008/03/31/2234072.aspx

07年12月，我写了一篇《C++虚函数表解析》的文章，引起了大家的兴趣。有很多朋友对我的文章留了言，有鼓励我的，有批评我的，还有很多问问题的。我在这里一并对大家的留言表示感谢。这也是我为什么再写一篇续言的原因。因为，在上一篇文章中，我用了的示例都是非常简单的，主要是为了说明一些机理上的问题，也是为了图一些表达上方便和简单。不想，这篇文章成为了打开C++对象模型内存布局的一个引子，引发了大家对C++对象的更深层次的讨论。当然，我之前的文章还有很多方面没有涉及，从我个人感觉下来，在谈论虚函数表里，至少有以下这些内容没有涉及：

1）有成员变量的情况。

2）有重复继承的情况。

3）有虚拟继承的情况。

4）有钻石型虚拟继承的情况。

这些都是我本篇文章需要向大家说明的东西。所以，这篇文章将会是《C++虚函数表解析》的一个续篇，也是一篇高级进阶的文章。我希望大家在读这篇文章之前对C++有一定的基础和了解，并能先读我的上一篇文章。因为这篇文章的深度可能会比较深，而且会比较杂乱，我希望你在读本篇文章时不会有大脑思维紊乱导致大脑死机的情况。;-)

对象的影响因素
 

简而言之，我们一个类可能会有如下的影响因素：

1）成员变量

2）虚函数（产生虚函数表）

3）单一继承（只继承于一个类）

4）多重继承（继承多个类）

5）重复继承（继承的多个父类中其父类有相同的超类）

6）虚拟继承（使用virtual方式继承，为了保证继承后父类的内存布局只会存在一份）

上述的东西通常是C++这门语言在语义方面对对象内部的影响因素，当然，还会有编译器的影响（比如优化），还有字节对齐的影响。在这里我们都不讨论，我们只讨论C++语言上的影响。

本篇文章着重讨论下述几个情况下的C++对象的内存布局情况。

1）单一的一般继承（带成员变量、虚函数、虚函数覆盖）

2）单一的虚拟继承（带成员变量、虚函数、虚函数覆盖）

3）多重继承（带成员变量、虚函数、虚函数覆盖）

4）重复多重继承（带成员变量、虚函数、虚函数覆盖）

5）钻石型的虚拟多重继承（带成员变量、虚函数、虚函数覆盖）

我们的目标就是，让事情越来越复杂。

知识复习
 

我们简单地复习一下，我们可以通过对象的地址来取得虚函数表的地址，如：

          typedef void(*Fun)(void);
 

            Base b;
 

            Fun pFun = NULL;
 

            cout << "虚函数表地址：" << (int*)(&b) << endl;
            cout << "虚函数表 — 第一个函数地址：" << (int*)*(int*)(&b) << endl;
 

            // Invoke the first virtual function 
            pFun = (Fun)*((int*)*(int*)(&b));
            pFun();
 

我们同样可以用这种方式来取得整个对象实例的内存布局。因为这些东西在内存中都是连续分布的，我们只需要使用适当的地址偏移量，我们就可以获得整个内存对象的布局。

本篇文章中的例程或内存布局主要使用如下编译器和系统：

1）Windows XP 和 VC++ 2003

2）Cygwin 和 G++ 3.4.4

单一的一般继承
 

下面，我们假设有如下所示的一个继承关系：

请注意，在这个继承关系中，父类，子类，孙子类都有自己的一个成员变量。而了类覆盖了父类的f()方法，孙子类覆盖了子类的g_child()及其超类的f()。

我们的源程序如下所示：

class Parent {
public:
    int iparent;
    Parent ():iparent (10) {}
    virtual void f() { cout << " Parent::f()" << endl; }
    virtual void g() { cout << " Parent::g()" << endl; }
    virtual void h() { cout << " Parent::h()" << endl; }
 

};
 

class Child : public Parent {
public:
    int ichild;
    Child():ichild(100) {}
    virtual void f() { cout << "Child::f()" << endl; }
    virtual void g_child() { cout << "Child::g_child()" << endl; }
    virtual void h_child() { cout << "Child::h_child()" << endl; }
};
 

class GrandChild : public Child{
public:
    int igrandchild;
    GrandChild():igrandchild(1000) {}
    virtual void f() { cout << "GrandChild::f()" << endl; }
    virtual void g_child() { cout << "GrandChild::g_child()" << endl; }
    virtual void h_grandchild() { cout << "GrandChild::h_grandchild()" << endl; }
};
我们使用以下程序作为测试程序：（下面程序中，我使用了一个int** pVtab 来作为遍历对象内存布局的指针，这样，我就可以方便地像使用数组一样来遍历所有的成员包括其虚函数表了，在后面的程序中，我也是用这样的方法的，请不必感到奇怪，）

    typedef void(*Fun)(void);

    GrandChild gc;
   
 

    int** pVtab = (int**)&gc;
 

    cout << "[0] GrandChild::_vptr->" << endl;
    for (int i=0; (Fun)pVtab[0][i]!=NULL; i++){
                pFun = (Fun)pVtab[0][i];
                cout << "    ["<<i<<"] ";
                pFun();
    }
    cout << "[1] Parent.iparent = " << (int)pVtab[1] << endl;
    cout << "[2] Child.ichild = " << (int)pVtab[2] << endl;
    cout << "[3] GrandChild.igrandchild = " << (int)pVtab[3] << endl;
 

其运行结果如下所示：（在VC++ 2003和G++ 3.4.4下）

使用图片表示如下：

可见以下几个方面：

1）虚函数表在最前面的位置。

2）成员变量根据其继承和声明顺序依次放在后面。

3）在单一的继承中，被overwrite的虚函数在虚函数表中得到了更新。

多重继承

下面，再让我们来看看多重继承中的情况，假设有下面这样一个类的继承关系。注意：子类只overwrite了父类的f()函数，而还有一个是自己的函数（我们这样做的目的是为了用g1()作为一个标记来标明子类的虚函数表）。而且每个类中都有一个自己的成员变量：

我们的类继承的源代码如下所示：父类的成员初始为10，20，30，子类的为100

class Base1 {
public:
    int ibase1;
    Base1():ibase1(10) {}
    virtual void f() { cout << "Base1::f()" << endl; }
    virtual void g() { cout << "Base1::g()" << endl; }
    virtual void h() { cout << "Base1::h()" << endl; }
 

};
 

class Base2 {
public:
    int ibase2;
    Base2():ibase2(20) {}
    virtual void f() { cout << "Base2::f()" << endl; }
    virtual void g() { cout << "Base2::g()" << endl; }
    virtual void h() { cout << "Base2::h()" << endl; }
};
 

class Base3 {
public:
    int ibase3;
    Base3():ibase3(30) {}
    virtual void f() { cout << "Base3::f()" << endl; }
    virtual void g() { cout << "Base3::g()" << endl; }
    virtual void h() { cout << "Base3::h()" << endl; }
};
 

class Derive : public Base1, public Base2, public Base3 {
public:
    int iderive;
    Derive():iderive(100) {}
    virtual void f() { cout << "Derive::f()" << endl; }
    virtual void g1() { cout << "Derive::g1()" << endl; }
};

我们通过下面的程序来查看子类实例的内存布局：下面程序中，注意我使用了一个s变量，其中用到了sizof(Base)来找下一个类的偏移量。（因为我声明的是int成员，所以是4个字节，所以没有对齐问题。关于内存的对齐问题，大家可以自行试验，我在这里就不多说了）

             typedef void(*Fun)(void);

               Derive d;
 

                int** pVtab = (int**)&d;
 

                cout << "[0] Base1::_vptr->" << endl;
                pFun = (Fun)pVtab[0][0];
                cout << "     [0] ";
                pFun();
 

                pFun = (Fun)pVtab[0][1];
                cout << "     [1] ";pFun();
 

                pFun = (Fun)pVtab[0][2];
                cout << "     [2] ";pFun();
 

                pFun = (Fun)pVtab[0][3];
                cout << "     [3] "; pFun();
 

                pFun = (Fun)pVtab[0][4];
                cout << "     [4] "; cout<<pFun<<endl;
 

                cout << "[1] Base1.ibase1 = " << (int)pVtab[1] << endl;
 

 

                int s = sizeof(Base1)/4;
 

                cout << "[" << s << "] Base2::_vptr->"<<endl;
                pFun = (Fun)pVtab[s][0];
                cout << "     [0] "; pFun();
 

                Fun = (Fun)pVtab[s][1];
                cout << "     [1] "; pFun();
 

                pFun = (Fun)pVtab[s][2];
                cout << "     [2] "; pFun();
 

                pFun = (Fun)pVtab[s][3];
                out << "     [3] ";
                cout<<pFun<<endl;
 

                cout << "["<< s+1 <<"] Base2.ibase2 = " << (int)pVtab[s+1] << endl;
 

                s = s + sizeof(Base2)/4;

                cout << "[" << s << "] Base3::_vptr->"<<endl;
                pFun = (Fun)pVtab[s][0];
                cout << "     [0] "; pFun();
 

                pFun = (Fun)pVtab[s][1];
                cout << "     [1] "; pFun();
 

                pFun = (Fun)pVtab[s][2];
                cout << "     [2] "; pFun();
 

                pFun = (Fun)pVtab[s][3];
                 cout << "     [3] ";
                cout<<pFun<<endl;
 

                s++;
                cout << "["<< s <<"] Base3.ibase3 = " << (int)pVtab[s] << endl;
                s++;
                cout << "["<< s <<"] Derive.iderive = " << (int)pVtab[s] << endl;

 

其运行结果如下所示：（在VC++ 2003和G++ 3.4.4下）

使用图片表示是下面这个样子：

 

我们可以看到：

1） 每个父类都有自己的虚表。

2） 子类的成员函数被放到了第一个父类的表中。

3） 内存布局中，其父类布局依次按声明顺序排列。

4） 每个父类的虚表中的f()函数都被overwrite成了子类的f()。这样做就是为了解决不同的父类类型的指针指向同一个子类实例，而能够调用到实际的函数。

C++中的虚函数的作用主要是实现了多态的机制。关于多态，简而言之就是用父类型别的指针指向其子类的实例，然后通过父类的指针调用实际子类的成员函数。这种技术可以让父类的指针有“多种形态”，这是一种泛型技术。所谓泛型技术，说白了就是试图使用不变的代码来实现可变的算法。比如：模板技术，RTTI技术，虚函数技术，要么是试图做到在编译时决议，要么试图做到运行时决议。

关于虚函数的使用方法，我在这里不做过多的阐述。大家可以看看相关的C++的书籍。在这篇文章中，我只想从虚函数的实现机制上面为大家 一个清晰的剖析。

当然，相同的文章在网上也出现过一些了，但我总感觉这些文章不是很容易阅读，大段大段的代码，没有图片，没有详细的说明，没有比较，没有举一反三。不利于学习和阅读，所以这是我想写下这篇文章的原因。也希望大家多给我提意见。

言归正传，让我们一起进入虚函数的世界。

虚函数表
 

对C++ 了解的人都应该知道虚函数（Virtual Function）是通过一张虚函数表（Virtual Table）来实现的。简称为V-Table。在这个表中，主是要一个类的虚函数的地址表，这张表解决了继承、覆盖的问题，保证其容真实反应实际的函数。这样，在有虚函数的类的实例中这个表被分配在了这个实例的内存中，所以，当我们用父类的指针来操作一个子类的时候，这张虚函数表就显得由为重要了，它就像一个地图一样，指明了实际所应该调用的函数。

这里我们着重看一下这张虚函数表。C++的编译器应该是保证虚函数表的指针存在于对象实例中最前面的位置（这是为了保证取到虚函数表的有最高的性能——如果有多层继承或是多重继承的情况下）。 这意味着我们通过对象实例的地址得到这张虚函数表，然后就可以遍历其中函数指针，并调用相应的函数。

听我扯了那么多，我可以感觉出来你现在可能比以前更加晕头转向了。 没关系，下面就是实际的例子，相信聪明的你一看就明白了。

假设我们有这样的一个类：

class Base {
     public:
            virtual void f() { cout << "Base::f" << endl; }
            virtual void g() { cout << "Base::g" << endl; }
            virtual void h() { cout << "Base::h" << endl; }
 

};
 

按照上面的说法，我们可以通过Base的实例来得到虚函数表。 下面是实际例程：

          typedef void(*Fun)(void);
 

            Base b;
 

            Fun pFun = NULL;
 

            cout << "虚函数表地址：" << (int*)(&b) << endl;
            cout << "虚函数表 — 第一个函数地址：" << (int*)*(int*)(&b) << endl;
 

            // Invoke the first virtual function 
            pFun = (Fun)*((int*)*(int*)(&b));
            pFun();
 

实际运行经果如下：(Windows XP+VS2003,  Linux 2.6.22 + GCC 4.1.3)

虚函数表地址：0012FED4
虚函数表 — 第一个函数地址：0044F148
Base::f
 

通过这个示例，我们可以看到，我们可以通过强行把&b转成int *，取得虚函数表的地址，然后，再次取址就可以得到第一个虚函数的地址了，也就是Base::f()，这在上面的程序中得到了验证（把int* 强制转成了函数指针）。通过这个示例，我们就可以知道如果要调用Base::g()和Base::h()，其代码如下：

            (Fun)*((int*)*(int*)(&b)+0);  // Base::f()
            (Fun)*((int*)*(int*)(&b)+1);  // Base::g()
            (Fun)*((int*)*(int*)(&b)+2);  // Base::h()
 

这个时候你应该懂了吧。什么？还是有点晕。也是，这样的代码看着太乱了。没问题，让我画个图解释一下。如下所示：

注意：在上面这个图中，我在虚函数表的最后多加了一个结点，这是虚函数表的结束结点，就像字符串的结束符“\0”一样，其标志了虚函数表的结束。这个结束标志的值在不同的编译器下是不同的。在WinXP+VS2003下，这个值是NULL。而在Ubuntu 7.10 + Linux 2.6.22 + GCC 4.1.3下，这个值是如果1，表示还有下一个虚函数表，如果值是0，表示是最后一个虚函数表。

下面，我将分别说明“无覆盖”和“有覆盖”时的虚函数表的样子。没有覆盖父类的虚函数是毫无意义的。我之所以要讲述没有覆盖的情况，主要目的是为了给一个对比。在比较之下，我们可以更加清楚地知道其内部的具体实现。

一般继承（无虚函数覆盖）
 

下面，再让我们来看看继承时的虚函数表是什么样的。假设有如下所示的一个继承关系：

请注意，在这个继承关系中，子类没有重载任何父类的函数。那么，在派生类的实例中，其虚函数表如下所示：

对于实例：Derive d; 的虚函数表如下：

我们可以看到下面几点：

1）虚函数按照其声明顺序放于表中。

2）父类的虚函数在子类的虚函数前面。

 

我相信聪明的你一定可以参考前面的那个程序，来编写一段程序来验证。

 

 

 

一般继承（有虚函数覆盖）

 

覆盖父类的虚函数是很显然的事情，不然，虚函数就变得毫无意义。下面，我们来看一下，如果子类中有虚函数重载了父类的虚函数，会是一个什么样子？假设，我们有下面这样的一个继承关系。

为了让大家看到被继承过后的效果，在这个类的设计中，我只覆盖了父类的一个函数：f()。那么，对于派生类的实例，其虚函数表会是下面的一个样子：

 

我们从表中可以看到下面几点，

1）覆盖的f()函数被放到了虚表中原来父类虚函数的位置。

2）没有被覆盖的函数依旧。

 

这样，我们就可以看到对于下面这样的程序，

 

            Base *b = new Derive();

b->f();

 

由b所指的内存中的虚函数表的f()的位置已经被Derive::f()函数地址所取代，于是在实际调用发生时，是Derive::f()被调用了。这就实现了多态。

 

 

 

多重继承（无虚函数覆盖）

 

下面，再让我们来看看多重继承中的情况，假设有下面这样一个类的继承关系。注意：子类并没有覆盖父类的函数。

 

 

 

对于子类实例中的虚函数表，是下面这个样子：

 

我们可以看到：

1） 每个父类都有自己的虚表。

2） 子类的成员函数被放到了第一个父类的表中。（所谓的第一个父类是按照声明顺序来判断的）

 

这样做就是为了解决不同的父类类型的指针指向同一个子类实例，而能够调用到实际的函数。

 

 

 

 

多重继承（有虚函数覆盖）

 

下面我们再来看看，如果发生虚函数覆盖的情况。

 

下图中，我们在子类中覆盖了父类的f()函数。

 

 

下面是对于子类实例中的虚函数表的图：

 

 

我们可以看见，三个父类虚函数表中的f()的位置被替换成了子类的函数指针。这样，我们就可以任一静态类型的父类来指向子类，并调用子类的f()了。如：

Derive d;
            Base1 *b1 = &d;
            Base2 *b2 = &d;
            Base3 *b3 = &d;
            b1->f(); //Derive::f()
            b2->f(); //Derive::f()
            b3->f(); //Derive::f()
 

            b1->g(); //Base1::g()
            b2->g(); //Base2::g()
            b3->g(); //Base3::g()
 

 

安全性
 

每次写C++的文章，总免不了要批判一下C++。这篇文章也不例外。通过上面的讲述，相信我们对虚函数表有一个比较细致的了解了。水可载舟，亦可覆舟。下面，让我们来看看我们可以用虚函数表来干点什么坏事吧。

 

一、通过父类型的指针访问子类自己的虚函数
我们知道，子类没有重载父类的虚函数是一件毫无意义的事情。因为多态也是要基于函数重载的。虽然在上面的图中我们可以看到Base1的虚表中有Derive的虚函数，但我们根本不可能使用下面的语句来调用子类的自有虚函数：

 

          Base1 *b1 = new Derive();
            b1->f1();  //编译出错
 

任何妄图使用父类指针想调用子类中的未覆盖父类的成员函数的行为都会被编译器视为非法，所以，这样的程序根本无法编译通过。但在运行时，我们可以通过指针的方式访问虚函数表来达到违反C++语义的行为。（关于这方面的尝试，通过阅读后面附录的代码，相信你可以做到这一点）

 

 

二、访问non-public的虚函数
另外，如果父类的虚函数是private或是protected的，但这些非public的虚函数同样会存在于虚函数表中，所以，我们同样可以使用访问虚函数表的方式来访问这些non-public的虚函数，这是很容易做到的。

 

如：

 

class Base {
    private:
            virtual void f() { cout << "Base::f" << endl; }
 

};
 

class Derive : public Base{
 

};
 

typedef void(*Fun)(void);
 

void main() {
    Derive d;
    Fun  pFun = (Fun)*((int*)*(int*)(&d)+0);
    pFun();
}
 

 

结束语
C++这门语言是一门Magic的语言，对于程序员来说，我们似乎永远摸不清楚这门语言背着我们在干了什么。需要熟悉这门语言，我们就必需要了解C++里面的那些东西，需要去了解C++中那些危险的东西。不然，这是一种搬起石头砸自己脚的编程语言。

 

在文章束之前还是介绍一下自己吧。我从事软件研发有十个年头了，目前是软件开发技术主管，技术方面，主攻Unix/C/C++，比较喜欢网络上的技术，比如分布式计算，网格计算，P2P，Ajax等一切和互联网相关的东西。管理方面比较擅长于团队建设，技术趋势分析，项目管理。欢迎大家和我交流，我的MSN和Email是：haoel@hotmail.com 

 

附录一：VC中查看虚函数表
 

我们可以在VC的IDE环境中的Debug状态下展开类的实例就可以看到虚函数表了（并不是很完整的）

附录 二：例程

下面是一个关于多重继承的虚函数表访问的例程：

#include <iostream>
using namespace std;
 

class Base1 {
public:
            virtual void f() { cout << "Base1::f" << endl; }
            virtual void g() { cout << "Base1::g" << endl; }
            virtual void h() { cout << "Base1::h" << endl; }
 

};
 

class Base2 {
public:
            virtual void f() { cout << "Base2::f" << endl; }
            virtual void g() { cout << "Base2::g" << endl; }
            virtual void h() { cout << "Base2::h" << endl; }
};
 

class Base3 {
public:
            virtual void f() { cout << "Base3::f" << endl; }
            virtual void g() { cout << "Base3::g" << endl; }
            virtual void h() { cout << "Base3::h" << endl; }
};
 

 

class Derive : public Base1, public Base2, public Base3 {
public:
            virtual void f() { cout << "Derive::f" << endl; }
            virtual void g1() { cout << "Derive::g1" << endl; }
};
 

 

typedef void(*Fun)(void);
 

int main()
{
            Fun pFun = NULL;
 

            Derive d;
            int** pVtab = (int**)&d;
 

            //Base1's vtable
            //pFun = (Fun)*((int*)*(int*)((int*)&d+0)+0);
            pFun = (Fun)pVtab[0][0];
            pFun();
 

            //pFun = (Fun)*((int*)*(int*)((int*)&d+0)+1);
            pFun = (Fun)pVtab[0][1];
            pFun();
 

            //pFun = (Fun)*((int*)*(int*)((int*)&d+0)+2);
            pFun = (Fun)pVtab[0][2];
            pFun();
 

            //Derive's vtable
            //pFun = (Fun)*((int*)*(int*)((int*)&d+0)+3);
            pFun = (Fun)pVtab[0][3];
            pFun();
 

            //The tail of the vtable
            pFun = (Fun)pVtab[0][4];
            cout<<pFun<<endl;
 

 

            //Base2's vtable
            //pFun = (Fun)*((int*)*(int*)((int*)&d+1)+0);
            pFun = (Fun)pVtab[1][0];
            pFun();
 

            //pFun = (Fun)*((int*)*(int*)((int*)&d+1)+1);
            pFun = (Fun)pVtab[1][1];
            pFun();
 

            pFun = (Fun)pVtab[1][2];
            pFun();
 

            //The tail of the vtable
            pFun = (Fun)pVtab[1][3];
            cout<<pFun<<endl;
 

 

 

            //Base3's vtable
            //pFun = (Fun)*((int*)*(int*)((int*)&d+1)+0);
            pFun = (Fun)pVtab[2][0];
            pFun();
 

            //pFun = (Fun)*((int*)*(int*)((int*)&d+1)+1);
            pFun = (Fun)pVtab[2][1];
            pFun();
 

            pFun = (Fun)pVtab[2][2];
            pFun();
 

            //The tail of the vtable
            pFun = (Fun)pVtab[2][3];
            cout<<pFun<<endl;
 

            return 0;
}

厚积薄发 2011-04-24 19:07 发表评论

]]>

C++对象模型系列：

本系列是主要是作者经验的总结且同时参考了大量的网络文章，希望能够给C++的学习者有所帮助，但是由于作者水平有限，难免有错，希望大家能够指出，我将虚心地向大家学习，与大家共同进步！本系列的开发环境是Windows 32+VS2008。

文章：

 指针和引用
 指针与数组
 指针与字符串
 堆栈与函数调用
 sizeof与对象内存布局
 单继承与虚函数表
 多重继承与虚函数表
 虚继承与虚函数表
 类型转化

参考：

1) C++对象模型
 C++对象模型笔记：http://blog.csdn.net/ZengMuAnSha/archive/2004/10/13/135477.aspx
 C++对象内存布局1：http://blog.csdn.net/haoel/archive/2008/10/15/3081328.aspx
 C++对象内存布局1：http://blog.csdn.net/haoel/archive/2008/10/15/3081385.aspx
 C++虚函数表解析： http://blog.csdn.net/haoel/archive/2007/12/18/1948051.aspx
 字节对齐1：http://blog.csdn.net/xuegao007/archive/2007/07/26/1708349.aspx
 字节对齐2：http://blog.csdn.net/xuegao007/archive/2007/07/26/1708355.aspx
 字节对齐3：http://blog.csdn.net/xuegao007/archive/2007/07/26/1708360.aspx
 sizeof : http://blog.csdn.net/xuegao007/archive/2007/08/23/1756047.aspx
 C++内存对象大会战1：http://blog.csdn.net/xuegao007/archive/2007/08/03/1723765.aspx
 C++内存对象大会战2：http://blog.csdn.net/xuegao007/archive/2007/08/03/1723766.aspx
 C++内存管理详解 ： http://www.cnblogs.com/dazhong/articles/721704.html
 C++内存布局 ：http://www.cnblogs.com/len3d/archive/2007/09/26/906899.html
 Visual C++ 8.0对象布局的奥秘：虚函数、多继承、虚拟继承 ： http://www.cnblogs.com/neoragex2002/archive/2007/11/01/VC8_Object_Layout_Secret.html
 关于typeid和RTTI的问答  ：http://blog.csdn.net/gxj1680/archive/2009/01/05/3715364.aspx
 字符串与数组工具收藏：http://tfzxbookshell.spaces.live.com/blog/cns!EB39D7FA27BCD1A1!902.entry
 memset ,memcpy 和strcpy 的根本区别？:http://tfzxbookshell.spaces.live.com/blog/cns!EB39D7FA27BCD1A1!904.entry
 函数调用约定和堆栈：http://www.fmddlmyy.cn/text12.html
 Win32程序函数调用时堆栈变化情况分析收藏：
http://www.cnblogs.com/hellohuan/archive/2008/07/07/1237371.html
http://blog.csdn.net/wenjie2005/archive/2008/01/09/2031377.aspx
C++ sizeof 使用规则及陷阱分析: http://freeman.cnblogs.com/articles/sizeof.html
What static_cast<> is actually doing:http://www.codeproject.com/KB/cpp/static_cast.aspx
Using generics in C++/CLI:http://www.codeproject.com/KB/mcpp/cppcligenerics.aspx
Type Casting:
http://www.cplusplus.com/doc/tutorial/typecasting.html
http://en.wikipedia.org/wiki/Typeid
type_info:
http://msdn.microsoft.com/zh-cn/library/70ky2y6k(en-us,VS.80).aspx
http://www.cplusplus.com/reference/std/typeinfo/type_info.html
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=120
http://www.atnf.csiro.au/computing/software/sol2docs/manuals/c++/prog_guide/RTTI.html
http://www.linuxtopia.org/online_books/programming_books/c++_practical_programming/c++_practical_programming_208.html
http://en.wikibooks.org/wiki/C%2B%2B_Programming/RTTI
http://docs.hp.com/en/B3901-90024/ch06s05.html
各种cast：
http://www.codeproject.com/KB/mcpp/castingbasics.aspx
http://www.cplusplus.com/doc/tutorial/typecasting.html
http://blog.baisi.net/?441896/viewspace-4063
http://blog.csdn.net/singno116/archive/2008/04/18/2304962.aspx
http://blog.chinaunix.net/u2/70445/showart_1357610.html
http://read.newbooks.com.cn/info/50236.html

谢谢！