RTY 实践出真知

　　静态链接库（Lib）和动态链接库（DLL）的问题困扰了我很长时间，而当中关键的问题是两者有何联系？又有何区别呢？怎么创建？怎么使用？使用的过程中要注意什么？一直想把这个问题总结一下。

　　在windows下一般可以看到后缀为dll和后缀为lib的文件，但这两种文件可以分为三种库，分别是动态链接库（Dynamic-Link Libraries），目标库（Object Libraries）和导入库（Import Libraries），下面一一解释这三种库。

目标库（Object Libraries）

目标库又叫静态链接库，是扩展名为.LIB的文件，包括了用户程序要用到的各种函数。它在用户程序进行链接时，“静态链接”到可执行程序文件当中。例如，在VC++中最常使用到的C运行时目标库文件就是LIBC.LIB。在链接应用程序时常使用所谓“静态链接”的方法，即将各个目标文件(.obj)、运行时函数库(.lib)以及已编译的资源文件(.res)链接到一起，形成一个可执行文件(.exe)。使用静态链接时，可执行文件需要使用的各种函数和资源都已包含到文件中。这样做的缺点是对于多个程序都使用的相同函数和资源要重复链接到exe文件中，使程序变大、占用内存增加。  

导入库（Import Libraries）

导入库是一种特殊形式的目标库文件形式。和目标库文件一样，导入库文件的扩展名也是.LIB，也是在用户程序被链接时，被“静态链接”到可执行文件当中。但是不同的是，导入库文件中并不包含有程序代码。相应的，它包含了相关的链接信息，帮助应用程序在可执行文件中建立起正确的对应于动态链接库的重定向表。比如KERNEL32.LIB、USER32.LIB和GDI32.LIB就是我们常用到的导入库，通过它们，我们就可以调用Windows提供的函数了。如果我们在程序中使用到了Rectangle这个函数，GDI32.LIB就可以告诉链接器，这个函数在GDI32.DLL动态链接库文件中。这样，当用户程序运行时，它就知道“动态链接”到GDI32.DLL模块中以使用这个函数。其实说白了导入库就是一个索引，一个dll动态链接库的索引表，这是我的理解。

动态链接库（Dynamic-Link Libraries）

“动态链接”是将一些公用的函数或资源组织成动态链接库文件(.dll)，当某个需要使用dll中的函数或资源的程序启动时(准确的说是初始化时)，系统将该dll映射到调用进程的虚拟地址空间、增加该dll的引用计数值，然后当实际使用到该dll时操作系统就将该dll载入内存；如果使用该dll的所有程序都已结束，则系统将该库从内存中移除。使用同一dll的各个进程在运行时共享dll的代码，但是对于dll中的数据则各有一份拷贝(当然也有在dll中共享数据的方法)。 动态链接库中可以定义两种函数：输出函数和内部函数。输出函数可以被其他模块调用，内部函数只能被动态链接库本身调用。动态链接库也可以输出数据，但这些数据通常只被它自己的函数所使用。

　　如我们所知，Windows程序都是一些可执行文件，它们可以创建并显示一个或多个窗体，使用消息循环来接收用户的输入。但是动态链接库并不能直接被执行，它们一般也不会接收消息。它们只是一些包含着函数的独立文件，这些函数可以被Windows程序或者其它DLL调用以完成某项任务。 
　　“动态链接”是指Windows程序在运行时才把自己需要存在于某个库中的函数链接进来。“静态链接”是指Windows程序在编译阶段就把各种对象模块（.OBJ）、运行时库（.LIB）和资源文件（.RES）链接到一起以创建一个可执行文件（.EXE）。 
　　DERNAL32.DLL，USER32.DLL，GDI32.DLL，各种驱动程序如KEYBOARD.DRV，SYSTEM.DRV和MOUSE.DRV，显卡和打印机驱动程序等都是动态链接库。这些库可以被所有的Windows程序共同使用。 
有某些动态链接库（如字体文件）称为“resource-only”。它们只包括数据，而不包括代码。因此，动态链接库的目的之一就是为许多不同的程序提供函数和资源。在传统的操作系统里，用户程序在运行时只能调用操作系统自身的某些函数。而在Windows操作系统下，模块或程序调用另一个模块中的函数来执行是一种非常普遍的操作。因此，从某种角度看，对DLL进行编程，其实是在对Windows操作系统作扩展，也可以看作是在对用户程序作扩展。 
　　动态链接库模块可以有其它的扩展名，但是标准的扩展名是.DLL。只有具有标准扩展句的动态链接库模块才可以被Windows自动加载。而如果是其它扩展名的动态链接库模块，程序必须使用LoadLibrary或者LoadLibraryEx函数来显示加载。 
　　我们可以发现，在大型的应用软件中，会常常使用到动态链接库技术。举个例子，假如我们要写一个大型的应用软件，其中包括了多个程序。我们可以发现很多程序可能都会使用到一些同样的通用的函数。我们可以把这些通用的函数放到某个目标库文件中（.LIB），然后在链接是把它加到每个程序中进行静态链接。但是这是一种非常浪费的方法，因为每个程序模块中都会包括这些通用函数的独立拷贝。另外，如果我们要改变库文件中的某个函数，就必须把所有使用到这个函数的程序都重新编译一遍。但是，如果我们使用动态链接库的技术，把所有这些通用函数都放到一个动态链接库文件当中，我们就可以解决以上提到的各种问题。首先，动态链接库在硬盘上只保留一个拷贝，程序只是在运行时才会调用其中使用到的函数，这样我们就可以节省大量的程序存储和运行空间。其次，如果要修改某个通用函数时，只要调用接口没有改变，只是改变它的实现方法，那么我们就不必对每个用到它的程序都进行重新编译，而只要把动态链接库模块重新编译一遍就可以了。 
　　动态链接库模块也可以作为一个单独的产品来发布。这样程序开发人员就可以使用第三方的模块来开发自己的应用程序，提高了程序的复用程序，也节省了大量的时间和精力。

 　　目标库和导入库都是在程序开发过程中才使用到的，而动态链接库是在程序运行时才使用的。在程序运行时，相应的动态链接库文件必须已经保存在硬盘上了。另外，如果要使用动态链接库文件，该文件必须要保存在同.EXE文件同一个目录下，或者保存在当前目录、Windows系统目录、Windows目录或环境变量中PATH参数指定的目录下。程序也是按照这个顺序来搜寻它需要的动态链接库文件的。

创建静态链接库（Lib）

　　创建静态链接库比较简单，创建win32控制台程序，选择静态库，这里我没有选择上预编译头。生成工程以后就像定义一般的函数般，定义放在头文件，然后实现放在cpp文件里头，直接build就出来一个静态的lib了，发布时附上头文件给使用者就可以。

创建动态链接库（DLL）

用SDK创建一个简单的dll文件

在VC++中选择新建一个Win32 Dynamic-Link Library。需要建立一个c/c++ head file和一个c/c++ source file并加入工程。头文件中内容为输出函数的声明，源文件中内容为DllMain函数和输出函数的定义。下面是一个最简单的例子。

 

 

头文件代码如下： 

 

代码

#ifdef TEST_CREATE_DLL_EXPORTS
#define TEST_CREATE_DLL_API __declspec(dllexport)
#else
#define TEST_CREATE_DLL_API __declspec(dllimport)
#endif

// This class is exported from the test_create_dll.dll
class TEST_CREATE_DLL_API Ctest_create_dll {
public:
    Ctest_create_dll(void);
    // TODO: add your methods here.
};

extern TEST_CREATE_DLL_API int ntest_create_dll;

TEST_CREATE_DLL_API int fntest_create_dll(void);

 

在创建工程的时候TEST_CREATE_DLL_EXPORTS就已经在预定义处定义过，生成导出dll。

头文件预处理中的__declspec是微软增加的“C扩展类存储属性”(C Extended Storage-Class Attributes)，它指明一个给出的实例被存储为一种微软特定的类存储属性，可以为thread,naked,dllimport或dllexport. [MSDN原文：The extended attribute syntax for specifying storage-class information uses the __declspec keyword, which specifies that an instance of a given type is to be stored with a Microsoft-specific storage-class attribute (thread, naked, dllimport, or dllexport).] 输出函数必须指明为CALLBACK。 DllMain是dll的入口点函数。也可以不写它。DllMain必须返回TRUE，否则系统将终止程序并弹出一个“启动程序时出错”对话框。 编译链接后，得到动态链接库文件dlldemo.dll和输入库文件dlldemo.lib。

_declspec(dllexport) 

声明一个导出函数，是说这个函数要从本DLL导出。我要给别人用。一般用于dll中 。
省掉在DEF文件中手工定义导出哪些函数的一个方法。当然，如果你的DLL里全是C++的类的话，你无法在DEF里指定导出的函数，只能用__declspec(dllexport)导出类。

 

__declspec(dllimport)

声明一个导入函数，是说这个函数是从别的DLL导入。我要用。一般用于使用某个dll的exe中 。
不使用 __declspec(dllimport) 也能正确编译代码，但使用 __declspec(dllimport) 使编译器可以生成更好的代码。编译器之所以能够生成更好的代码，是因为它可以确定函数是否存在于 DLL 中，这使得编译器可以生成跳过间接寻址级别的代码，而这些代码通常会出现在跨 DLL 边界的函数调用中。但是，必须使用 __declspec(dllimport) 才能导入 DLL 中使用的变量。

相信写WIN32程序的人，做过DLL，都会很清楚__declspec(dllexport)的作用，它就是为了省掉在DEF文件中手工定义导出哪些函数的一个方法。当然，如果你的DLL里全是C++的类的话，你无法在DEF里指定导出的函数，只能用__declspec(dllexport)导出类。但是，MSDN文档里面，对于__declspec(dllimport)的说明让人感觉有点奇怪，先来看看MSDN里面是怎么说的：

不使用 __declspec(dllimport) 也能正确编译代码，但使用 __declspec(dllimport) 使编译器可以生成更好的代码。编译器之所以能够生成更好的代码，是因为它可以确定函数是否存在于 DLL 中，这使得编译器可以生成跳过间接寻址级别的代码，而这些代码通常会出现在跨 DLL 边界的函数调用中。但是，必须使用 __declspec(dllimport) 才能导入 DLL 中使用的变量。

extern "C"   

指示编译器用C语言方法给函数命名。

在制作DLL导出函数时由于C++存在函数重载，因此__declspec(dllexport)    function(int,int)    在DLL会被decorate，例如被decorate成为function_int_int，而且不同的编译器decorate的方法不同，造成了在用GetProcAddress取得function地址时的不便，使用extern "C"时，上述的decorate不会发生，因为C没有函数重载，但如此一来被extern"C"修饰的函数，就不具备重载能力，可以说extern 和extern "C"不是一回事。

C++编译器在生成DLL时，会对导出的函数进行名字改编，并且不同的编译器使用的改变规则不一样，因此改编后的名字会不一样。这样，如果利用不同的编译器分别生成DLL和访问该DLL的客户端代码程序的话，后者在访问该DLL的导出函数时会出现问题。为了实现通用性，需要加上限定符：extern “C”。

但是利用限定符extern “C”可以解决C++和C之间相互调用时函数命名的问题，但是这种方法有一个缺陷，就是不能用于导出一个类的成员函数，只能用于导出全局函数。LoadLibrary导入的函数名，对于非改编的函数，可以写函数名；对于改编的函数，就必须吧@和号码都写上，一样可以加载成功，可以试试看。

解决警告  inconsistent dll linkage

 inconsistent dll linkage警告是写dll时常遇到的一个问题，解决此警告的方法如下：

　　一般PREDLL_API工程依赖于是否定义了MYDLL_EXPORTS来决定宏展开为__declspec(dllexport)还是__declspec(dllimport)。展开为__declspec(dllexport)是DLL编译时的需要，通知编译器该函数是需要导出供外部调用的。展开为__declspec(dllimport)是给调用者用的，通知编译器，该函数是个外部导入函数。

对于工程设置里面的预定义宏，是最早被编译器看到的。所以当编译器编译DLL工程中的MYDLL.cpp时，因为看到前面有工程设置有定义MYDLL_EXPORTS，所以就把PREDLL_API展开为__declspec(dllexport)了。

这样做的目的是为了让DLL和调用者共用同一个h文件，在DLL项目中，定义MYDLL_EXPORTS，PREDLL_API就是导出；在调用该DLL的项目中，不定义MYDLL_EXPORTS，PREDLL_API就是导入。

使用静态链接库（Lib）

 

　　使用静态链接库需要库的开发者提供库的头文件以及lib文件，一般来说lib文件都比较大（相对导入库来说），静态链接库是将全部指令都包含入调用程序生成的EXE文件中，并不存在“导出某个函数提供给用户使用”的情况，就是要么全要，要么都不要。

使用动态链接库（DLL）

 

方法一： load-time dynamic linking (隐式调用)
　　在要调用dll的应用程序链接时，将dll的输入库文件(import library，.lib文件)包含进去。具体的做法是在源文件开头加一句#include ，然后就可以在源文件中调用dlldemo.dll中的输出文件了。

#pragma comment(lib, "***.lib") //通知编译器DLL的.lib文件所在路径及文件名，也可以不采用该语句，在属性栏——输入——附加依赖项处添加对应的lib就可以编译链接应用程序了。

extern "C" __declspec(dllimport) foo(); //声明导入函数

方法二： run-time dynamic linking （显式调用）
　　不必在链接时包含输入库文件，而是在源程序中使用LoadLibrary或LoadLibraryEx动态的载入dll。
　　主要步骤为(以demodll.dll为例): 

1) typedef函数原型和定义函数指针。
　　typedef void (CALLBACK* DllFooType)(void) ;
　　DllFooType pfnDllFoo = NULL ;
2) 使用LoadLibrary载入dll，并保存dll实例句柄
　　HINSTANCE dllHandle = NULL ;
　　... 
　　dllHandle = LoadLibrary(TEXT("dlldemo.dll"));
3) 使用GetProcAddress得到dll中函数的指针
　　pfnDllFoo = (DllFooType)GetProcAddress(dllHandle,TEXT("DllFoo")) ;
　　注意从GetProcAddress返回的指针必须转型为特定类型的函数指针。
4)检验函数指针，如果不为空则可调用该函数 
　　if(pfnDllFoo!=NULL)
　　DllFoo() ;
5)使用FreeLibrary卸载dll
　　FreeLibrary(dllHandle) ;

动态链接库（DLL）的优点

 

　　→节约内存；
　　→使应用程序“变瘦”；
　　→可单独修改动态链接库而不必与应用程序重新链接；
　　→可方便实现多语言联合编程(比如用VC++写个dll，然后在VB中调用)；
　　→可将资源打包；
　　→可在应用程序间共享内存
　　→......

 

杭州京都医院http://www.fjzzled.com/京都医院

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[] = "HellowWord"； 是在运行时赋值的；用数组比用指针速度要快一些，因为指针在底层汇编中需要用edx寄存器中转一下，而数组在栈上直接读取。

1.初识Visual Leak Detector
      灵活自由是C/C++语言的一大特色，而这也为C/C++程序员出了一个难题。当程序越来越复杂时，内存的管理也会变得越加复杂，稍有不慎就会出现内存问题。内存泄漏是最常见的内存问题之一。内存泄漏如果不是很严重，在短时间内对程序不会有太大的影响，这也使得内存泄漏问题有很强的隐蔽性，不容易被发现。然而不管内存泄漏多么轻微，当程序长时间运行时，其破坏力是惊人的，从性能下降到内存耗尽，甚至会影响到其他程序的正常运行。另外内存问题的一个共同特点是，内存问题本身并不会有很明显的现象，当有异常现象出现时已时过境迁，其现场已非出现问题时的现场了，这给调试内存问题带来了很大的难度。            

Visual Leak Detector是一款用于Visual C++的免费的内存泄露检测工具。可以在http://www.codeproject.com/tools/visualleakdetector.asp下载到。相比较其它的内存泄露检测工具，它在检测到内存泄漏的同时，还具有如下特点：

1、 可以得到内存泄漏点的调用堆栈，如果可以的话，还可以得到其所在文件及行号；

2、 可以得到泄露内存的完整数据；

3、 可以设置内存泄露报告的级别；

4、 它是一个已经打包的lib，使用时无须编译它的源代码。而对于使用者自己的代码，也只需要做很小的改动；

5、 他的源代码使用GNU许可发布，并有详尽的文档及注释。对于想深入了解堆内存管理的读者，是一个不错的选择。            

可见，从使用角度来讲，Visual Leak Detector简单易用，对于使用者自己的代码，唯一的修改是#include Visual Leak Detector的头文件后正常运行自己的程序，就可以发现内存问题。从研究的角度来讲，如果深入Visual Leak Detector源代码，可以学习到堆内存分配与释放的原理、内存泄漏检测的原理及内存操作的常用技巧等。      本文首先将介绍Visual Leak Detector的使用方法与步骤，然后再和读者一起初步的研究Visual Leak Detector的源代码，去了解Visual Leak Detector的工作原理。

2.使用Visual Leak Detector(1.0)
      下面让我们来介绍如何使用这个小巧的工具。      

首先从网站上下载zip包，解压之后得到vld.h, vldapi.h, vld.lib, vldmt.lib, vldmtdll.lib, dbghelp.dll等文件。将.h文件拷贝到Visual C++的默认include目录下，将.lib文件拷贝到Visual C++的默认lib目录下，便安装完成了。因为版本问题，如果使用windows 2000或者以前的版本，需要将dbghelp.dll拷贝到你的程序的运行目录下，或其他可以引用到的目录。      

接下来需要将其加入到自己的代码中。方法很简单，只要在包含入口函数的.cpp文件中包含vld.h就可以。如果这个cpp文件包含了stdafx.h，则将包含vld.h的语句放在stdafx.h的包含语句之后，否则放在最前面。如下是一个示例程序：

#include<vld.h>

void main()

{

　　…

}      

接下来让我们来演示如何使用Visual Leak Detector检测内存泄漏。下面是一个简单的程序，用new分配了一个int大小的堆内存，并没有释放。其申请的内存地址用printf输出到屏幕上。

#include<vld.h>

#include<stdlib.h>

#include<stdio.h> 

void f()

{   

　　int*p =newint(0x12345678);   

　　printf("p=%08x, ", p);

} 

void main()

{   

　　f();

}

编译运行后，在标准输出窗口得到：

p=003a89c0 

在Visual C++的Output窗口得到： 

WARNING: Visual Leak Detector detected memory leaks!

---------- Block 57 at 0x003A89C0: 4 bytes ---------- --57号块0x003A89C0地址泄漏了4个字节 

Call Stack:                                             --下面是调用堆栈   

d:\test\testvldconsole\testvldconsole\main.cpp (7): f --表示在main.cpp第7行的f()函数   

d:\test\testvldconsole\testvldconsole\main.cpp (14): main–双击以引导至对应代码处   

f:\rtm\vctools\crt_bld\self_x86\crt\src\crtexe.c (586): __tmainCRTStartup   

f:\rtm\vctools\crt_bld\self_x86\crt\src\crtexe.c (403): mainCRTStartup   

0x7C816D4F (File and line number not available): RegisterWaitForInputIdle 

Data:                                 --这是泄漏内存的内容，0x12345678   78 56 34 12                                                 

xV4..... ........ 

Visual Leak Detector detected 1 memory leak.   

第二行表示57号块有4字节的内存泄漏，地址为0x003A89C0，根据程序控制台的输出，可以知道，该地址为指针p。程序的第7行，f()函数里，在该地址处分配了4字节的堆内存空间，并赋值为0x12345678，这样在报告中，我们看到了这4字节同样的内容。

可以看出，对于每一个内存泄漏，这个报告列出了它的泄漏点、长度、分配该内存时的调用堆栈、和泄露内存的内容（分别以16进制和文本格式列出）。双击该堆栈报告的某一行，会自动在代码编辑器中跳到其所指文件的对应行。这些信息对于我们查找内存泄露将有很大的帮助。

这是一个很方便易用的工具，安装后每次使用时，仅仅需要将它头文件包含进来重新build就可以。而且，该工具仅在build Debug版的时候会连接到你的程序中，如果build Release版，该工具不会对你的程序产生任何性能等方面影响。所以尽可以将其头文件一直包含在你的源代码中。

3.Visual Leak Detector工作原理
　　下面让我们来看一下该工具的工作原理。      

　　在这之前，我们先来看一下Visual C++内置的内存泄漏检测工具是如何工作的。Visual C++内置的工具CRT Debug Heap工作原来很简单。在使用Debug版的malloc分配内存时，malloc会在内存块的头中记录分配该内存的文件名及行号。当程序退出时CRT会在main()函数返回之后做一些清理工作，这个时候来检查调试堆内存，如果仍然有内存没有被释放，则一定是存在内存泄漏。从这些没有被释放的内存块的头中，就可以获得文件名及行号。      　　这种静态的方法可以检测出内存泄漏及其泄漏点的文件名和行号，但是并不知道泄漏究竟是如何发生的，并不知道该内存分配语句是如何被执行到的。要想了解这些，就必须要对程序的内存分配过程进行动态跟踪。Visual Leak Detector就是这样做的。它在每次内存分配时将其上下文记录下来，当程序退出时，对于检测到的内存泄漏，查找其记录下来的上下文信息，并将其转换成报告输出。      

3.1初始化
　　Visual Leak Detector要记录每一次的内存分配，而它是如何监视内存分配的呢？Windows提供了分配钩子(allocation hooks)来监视调试堆内存的分配。它是一个用户定义的回调函数，在每次从调试堆分配内存之前被调用。在初始化时，Visual Leak Detector使用_CrtSetAllocHook注册这个钩子函数，这样就可以监视从此之后所有的堆内存分配了。      

　　如何保证在Visual Leak Detector初始化之前没有堆内存分配呢？全局变量是在程序启动时就初始化的，如果将Visual Leak Detector作为一个全局变量，就可以随程序一起启动。但是C/C++并没有约定全局变量之间的初始化顺序，如果其它全局变量的构造函数中有堆内存分配，则可能无法检测到。Visual Leak Detector使用了C/C++提供的#pragma init_seg来在某种程度上减少其它全局变量在其之前初始化的概率。根据#pragma init_seg的定义，全局变量的初始化分三个阶段：首先是compiler段，一般c语言的运行时库在这个时候初始化；然后是lib段，一般用于第三方的类库的初始化等；最后是user段，大部分的初始化都在这个阶段进行。Visual Leak Detector将其初始化设置在compiler段，从而使得它在绝大多数全局变量和几乎所有的用户定义的全局变量之前初始化。 

4.记录内存分配
　　一个分配钩子函数需要具有如下的形式：intYourAllocHook(intallocType,void*userData, size_t size,intblockType,longrequestNumber,constunsignedchar*filename,intlineNumber);      就像前面说的，它在Visual Leak Detector初始化时被注册，每次从调试堆分配内存之前被调用。这个函数需要处理的事情是记录下此时的调用堆栈和此次堆内存分配的唯一标识——requestNumber。      

　　得到当前的堆栈的二进制表示并不是一件很复杂的事情，但是因为不同体系结构、不同编译器、不同的函数调用约定所产生的堆栈内容略有不同，要解释堆栈并得到整个函数调用过程略显复杂。不过windows提供一个StackWalk64函数，可以获得堆栈的内容。StackWalk64的声明如下：BOOLStackWalk64( DWORDMachineType, HANDLEhProcess, HANDLEhThread, LPSTACKFRAME64StackFrame, PVOIDContextRecord, PREAD_PROCESS_MEMORY_ROUTINE64ReadMemoryRoutine, PFUNCTION_TABLE_ACCESS_ROUTINE64FunctionTableAccessRoutine, PGET_MODULE_BASE_ROUTINE64GetModuleBaseRoutine, PTRANSLATE_ADDRESS_ROUTINE64TranslateAddress);STACKFRAME64结构表示了堆栈中的一个frame。给出初始的STACKFRAME64，反复调用该函数，便可以得到内存分配点的调用堆栈了。   // Walk the stack.   while(count < _VLD_maxtraceframes) {       count++;       if(!pStackWalk64(architecture, m_process, m_thread, &frame, &context,                         NULL, pSymFunctionTableAccess64, pSymGetModuleBase64, NULL)) {           // Couldn't trace back through any more frames.           break;       }

QList<T> 的释放分两种情况：

1.T的类型为非指针，这时候直接调用clear()方法就可以释放了，看如下测试代码

#include <QtCore/QCoreApplication>#include <QList>#include <QString>

int main(int argc, char *argv[]){    QCoreApplication a(argc, argv);    typedef struct _test    {        int id;        QString name;        QString sex;    }Por_test;    QList<Por_test>  slist;    for (int i=0;i<100000;i++)    {        Por_test s;        s.id = 1;        s.name = QString("hello World!");        s.sex = QString("男");        slist.append(s);    }    slist.clear();    return a.exec();}

将上面代码中的slist.clear(); 注释掉，内存显示为如下（任务管理器里的截图）

如不去掉的话，内存显示如下图

2.T的类型为指针的情况，这时候直接调用clear()方法将不能释放，先看代码

#include <QtCore/QCoreApplication>#include <QList>#include <QString>int main(int argc, char *argv[]){    QCoreApplication a(argc, argv);    typedef struct _test    {        int id;        QString name;        QString sex;    }Por_test;    QList<Por_test *>  slist;    for (int i=0;i<100000;i++)    {        Por_test *s = new Por_test();        s->id = 1;        s->name = QString("hello World!");        s->sex = QString("男?");        slist.append(s);    }//    qDeleteAll(slist);    slist.clear();    return a.exec();}

上面代码运行后的内存情况如下图

说明当T的类型为指针时，调用clear()方法并不能释放其内存

此时void qDeleteAll ( const Container & c )方法将派上用场了，将上面代码中的注释去掉以后，

再次运行程序，此时的内存情况如下图

通过对比靓图，可以看出，内存已经释放，我们再来看下qt助手中qDeleteAll 方法的说明

void qDeleteAll ( ForwardIterator begin, ForwardIterator end )

Deletes all the items in the range [begin, end) using the C++ delete operator. The item type must be a pointer type (for example, QWidget *).

Example:

 QList<Employee *> list; list.append(new Employee("Blackpool", "Stephen")); list.append(new Employee("Twist", "Oliver")); qDeleteAll(list.begin(), list.end()); list.clear();

Notice that qDeleteAll() doesn't remove the items from the container; it merely calls delete on them. In the example above, we call clear() on the container to remove the items.

This function can also be used to delete items stored in associative containers, such as QMap and QHash. Only the objects stored in each container will be deleted by this function; objects used as keys will not be deleted.

See also forward iterators.

void qDeleteAll ( const Container & c )

This is an overloaded member function, provided for convenience.

This is the same as qDeleteAll(c.begin(), c.end()).

上面qDeleteAll 方法的说明，已经很清楚了，如果T为指针类型时，释放内存须在clear方法前加上qDeleteAll 方法。

app - 建立一个应用程序的makefile。这是默认值，所以如果模板没有被指定，这个将被使用。

lib - 建立一个库的makefile。

vcapp - 建立一个应用程序的Visual Studio项目文件。

vclib - 建立一个库的Visual Studio项目文件。

subdirs - 这是一个特殊的模板，它可以创建一个能够进入特定目录并且为一个项目文件生成makefile并且为它调用make的makefile。

“app”模板
“app”模板告诉qmake为建立一个应用程序生成一个makefile。当使用这个模板时，下面这些qmake系统变量是被承认的。你应该在你的.pro文件中使用它们来为你的应用程序指定特定信息。

HEADERS - 应用程序中的所有头文件的列表。

SOURCES - 应用程序中的所有源文件的列表。

FORMS - 应用程序中的所有.ui文件（由Qt设计器生成）的列表。

LEXSOURCES - 应用程序中的所有lex源文件的列表。

YACCSOURCES - 应用程序中的所有yacc源文件的列表。

TARGET - 可执行应用程序的名称。默认值为项目文件的名称。（如果需要扩展名，会被自动加上。）

DESTDIR - 放置可执行程序目标的目录。

DEFINES - 应用程序所需的额外的预处理程序定义的列表。

INCLUDEPATH - 应用程序所需的额外的包含路径的列表。

DEPENDPATH - 应用程序所依赖的搜索路径。

VPATH - 寻找补充文件的搜索路径。

DEF_FILE - 只有Windows需要：应用程序所要连接的.def文件。

RC_FILE - 只有Windows需要：应用程序的资源文件。

RES_FILE - 只有Windows需要：应用程序所要连接的资源文件。

CONFIG变量
配置变量指定了编译器所要使用的选项和所需要被连接的库。配置变量中可以添加任何东西，但只有下面这些选项可以被qmake识别。

下面这些选项控制着使用哪些编译器标志：

release - 应用程序将以release模式连编。如果“debug”被指定，它将被忽略。

debug - 应用程序将以debug模式连编。

warn_on - 编译器会输出尽可能多的警告信息。如果“warn_off”被指定，它将被忽略。

warn_off - 编译器会输出尽可能少的警告信息。

下面这些选项定义了所要连编的库/应用程序的类型：

qt - 应用程序是一个Qt应用程序，并且Qt库将会被连接。

thread - 应用程序是一个多线程应用程序。

x11 - 应用程序是一个X11应用程序或库。

windows - 只用于“app”模板：应用程序是一个Windows下的窗口应用程序。

console - 只用于“app”模板：应用程序是一个Windows下的控制台应用程序。

dll - 只用于“lib”模板：库是一个共享库（dll）。

staticlib - 只用于“lib”模板：库是一个静态库。

plugin - 只用于“lib”模板：库是一个插件，这将会使dll选项生效。

例如，如果你的应用程序使用Qt库，并且你想把它连编为一个可调试的多线程的应用程序，你的项目文件应该会有下面这行：

    CONFIG += qt thread debug注意，你必须使用“+=”，不要使用“=”，否则qmake就不能正确使用连编Qt的设置了，比如没法获得所编译的Qt库的类型了。

qmake高级概念
操作符

“=”操作符      分配一个值给一个变量
“+=”操作符     向一个变量的值的列表中添加一个值
“-=”操作符      从一个变量的值的列表中移去一个值
“*=”操作符      仅仅在一个值不存在于一个变量的值的列表中的时候，把它添加进去
“~=”操作符      替换任何与指定的值的正则表达式匹配的任何值 DEFINES ~= s/QT_[DT].+/QT
作用域
win32:thread {
        DEFINES += QT_THREAD_SUPPORT    } else:debug {        DEFINES += QT_NOTHREAD_DEBUG    } else {        warning("Unknown configuration")    }    }变量
到目前为止我们遇到的变量都是系统变量，比如DEFINES、SOURCES和HEADERS。你也可以为你自己创建自己的变量，这样你就可以在作用域中使用它们了。创建自己的变量很容易，只要命名它并且分配一些东西给它。比如：

    MY_VARIABLE = value你也可以通过在其它任何一个变量的变量名前加$$来把这个变量的值分配给当前的变量。例如：

   MY_DEFINES = $$DEFINESMY_DEFINES = $${DEFINES}
第二种方法允许你把一个变量和其它变量连接起来，而不用使用空格。qmake将允许一个变量包含任何东西（包括$(VALUE)，可以直接在makefile中直接放置，并且允许它适当地扩张，通常是一个环境变量）。无论如何，如果你需要立即设置一个环境变量，然后你就可以使用$$()方法。比如：

    MY_DEFINES = $$(ENV_DEFINES)这将会设置MY_DEFINES为环境变量ENV_DEFINES传递给.pro文件地值。另外你可以在替换的变量里调用内置函数。这些函数（不会和下一节中列举的测试函数混淆）列出如下：

join( variablename, glue, before, after )
这将会在variablename的各个值中间加入glue。如果这个变量的值为非空，那么就会在值的前面加一个前缀before和一个后缀after。只有variablename是必须的字段，其它默认情况下为空串。如果你需要在glue、before或者after中使用空格的话，你必须提供它们。

member( variablename, position )
这将会放置variablename的列表中的position位置的值。如果variablename不够长，这将会返回一个空串。variablename是唯一必须的字段，如果没有指定位置，则默认为列表中的第一个值。

find( variablename, substr )
这将会放置variablename中所有匹配substr的值。substr也可以是正则表达式，而因此将被匹配。

    MY_VAR = one two three four    MY_VAR2 = $$join(MY_VAR, " -L", -L) -Lfive    MY_VAR3 = $$member(MY_VAR, 2) $$find(MY_VAR, t.*)MY_VAR2将会包含“-Lone -Ltwo -Lthree -Lfour -Lfive”，并且MYVAR3将会包含“three two three”。

system( program_and_args )
这将会返回程序执行在标准输出/标准错误输出的内容，并且正像平时所期待地分析它。比如你可以使用这个来询问有关平台的信息。

    UNAME = $$system(uname -s)    contains( UNAME, [lL]inux ):message( This looks like Linux ($$UNAME) to me )测试函数
qmake提供了可以简单执行，但强大测试的内置函数。这些测试也可以用在作用域中（就像上面一样），在一些情况下，忽略它的测试值，它自己使用测试函数是很有用的。

contains( variablename, value )
如果value存在于一个被叫做variablename的变量的值的列表中，那么这个作用域中的设置将会被处理。例如：

    contains( CONFIG, thread ) {        DEFINES += QT_THREAD_SUPPORT    }如果thread存在于CONFIG变量的值的列表中时，那么QT_THREAD_SUPPORT将会被加入到DEFINES变量的值的列表中。

count( variablename, number )
如果number与一个被叫做variablename的变量的值的数量一致，那么这个作用域中的设置将会被处理。例如：

    count( DEFINES, 5 ) {        CONFIG += debug    }error( string )
这个函数输出所给定的字符串，然后会使qmake退出。例如：

    error( "An error has occured" )文本“An error has occured”将会被显示在控制台上并且qmake将会退出。

exists( filename )
如果指定文件存在，那么这个作用域中的设置将会被处理。例如：

    exists( /local/qt/qmake/main.cpp ) {        SOURCES += main.cpp    }如果/local/qt/qmake/main.cpp存在，那么main.cpp将会被添加到源文件列表中。

注意可以不用考虑平台使用“/”作为目录的分隔符。

include( filename )
项目文件在这一点时包含这个文件名的内容，所以指定文件中的任何设置都将会被处理。例如：

     include( myotherapp.pro )myotherapp.pro项目文件中的任何设置现在都会被处理。

isEmpty( variablename )
这和使用count( variablename, 0 )是一样的。如果叫做variablename的变量没有任何元素，那么这个作用域中的设置将会被处理。例如：

    isEmpty( CONFIG ) {        CONFIG += qt warn_on debug    }message( string )
这个函数只是简单地在控制台上输出消息。

    message( "This is a message" )文本“This is a message”被输出到控制台上并且对于项目文件的处理将会继续进行。

system( command )
特定指令被执行并且如果它返回一个1的退出值，那么这个作用域中的设置将会被处理。例如：

    system( ls /bin ) {        SOURCES += bin/main.cpp        HEADERS += bin/main.h    }所以如果命令ls /bin返回1，那么bin/main.cpp将被添加到源文件列表中并且bin/main.h将被添加到头文件列表中。

infile( filename, var, val )
如果filename文件（当它被qmake自己解析时）包含一个值为val的变量var，那么这个函数将会返回成功。你也可以不传递第三个参数（val），这时函数将只测试文件中是否分配有这样一个变量var。

以下为我的一个项目举例
# 项目目标：为一个库文件

TEMPLATE = lib# 编译项目文件所需头文件的路径INCLUDEPATH += ../common .# 目标文件路径DESTDIR=../lib# 条件依赖：Unix平台上 定义本想目的 UI目录， MOC目录， 目的目录unix {  UI_DIR = ../.ui  MOC_DIR = ../.moc  OBJECTS_DIR = ../.obj}# 本项目配置：CONFIG         += qt warn_on release thread# Input  头文件 ，源文件HEADERS += COMControllerThread.h \           DecodeSMS.h \           monitor_common.h \           monitor_interface.h \           MonitorThread.h \          UserEvent.h \           MyCOM.h \           MySMS.h \           MyTagHandle.h \          SMSParseThread.h \           tag_dict.hSOURCES += COMControllerThread.cpp \          DecodeSMS.cpp \           monitor_common.cpp \           monitor_interface.cpp \          MonitorThread.cpp \           MyCOM.cpp \           MySMS.cpp \           MyTagHandle.cpp \           SMSParseThread.cpp \           tag_dict.cpp注：qmake -project 可以生成pro文件（可以根据项目需要，编辑改文件）
qmake 可以生成Makefile文件
make 编译
使用qmake -project时，会把本目录及其子目录内所有.cpp .h文件加入到项目输入文件中，使用是注意移去其他无用的文件。
qmake生成的Makefile文件，可以根据需要做相应修改