"STREQUAL" "x86_64" Unknown arguments specified
解决：

if($ENV(COMPILING_TYPE) STREQUAL "x86_64")
改为：
if(($ENV(COMPILING_TYPE)) STREQUAL "x86_64")


O了！

  在头文件中，定义宏
#ifdef MYDLL_EXPORTS
#define MYDLL_API __declspec(dllexport)
#else
#define MYDLL_API __declspec(dllimport)
#endif

  现在，在变量m_structs前，添加：
template class MYDLL_API std::allocator<myStruct>;
template class MYDLL_API std::vector<myStruct, std::allocator<myStruct> >;
  这样，即可以了。

二.字节对齐对程序的影响:
    先让我们看几个例子吧(32bit,x86环境,gcc编译器):
设结构体如下定义：
struct A
{
    int a;
    char b;
    short c;
};
struct B
{
    char b;
    int a;
    short c;
};
现在已知32位机器上各种数据类型的长度如下:
char:1(有符号无符号同)   
short:2(有符号无符号同)   
int:4(有符号无符号同)   
long:4(有符号无符号同)   
float:4    double:8
那么上面两个结构大小如何呢?
结果是:
sizeof(strcut A)值为8
sizeof(struct B)的值却是12

结构体A中包含了4字节长度的int一个，1字节长度的char一个和2字节长度的short型数据一个,B也一样;按理说A,B大小应该都是7字节。
之所以出现上面的结果是因为编译器要对数据成员在空间上进行对齐。上面是按照编译器的默认设置进行对齐的结果,那么我们是不是可以改变编译器的这种默认对齐设置呢,当然可以.例如:
#pragma pack (2) /*指定按2字节对齐*/
struct C
{
    char b;
    int a;
    short c;
};
#pragma pack () /*取消指定对齐，恢复缺省对齐*/
sizeof(struct C)值是8。
修改对齐值为1：
#pragma pack (1) /*指定按1字节对齐*/
struct D
{
    char b;
    int a;
    short c;
};
#pragma pack () /*取消指定对齐，恢复缺省对齐*/
sizeof(struct D)值为7。
后面我们再讲解#pragma pack()的作用.

三.编译器是按照什么样的原则进行对齐的?
    先让我们看四个重要的基本概念：
1.数据类型自身的对齐值：
  对于char型数据，其自身对齐值为1，对于short型为2，对于int,float,double类型，其自身对齐值为4，单位字节。
2.结构体或者类的自身对齐值：其成员中自身对齐值最大的那个值。
3.指定对齐值：#pragma pack (value)时的指定对齐值value。
4.数据成员、结构体和类的有效对齐值：自身对齐值和指定对齐值中小的那个值。
有 了这些值，我们就可以很方便的来讨论具体数据结构的成员和其自身的对齐方式。有效对齐值N是最终用来决定数据存放地址方式的值，最重要。有效对齐N，就是 表示“对齐在N上”，也就是说该数据的"存放起始地址%N=0".而数据结构中的数据变量都是按定义的先后顺序来排放的。第一个数据变量的起始地址就是数 据结构的起始地址。结构体的成员变量要对齐排放，结构体本身也要根据自身的有效对齐值圆整(就是结构体成员变量占用总长度需要是对结构体有效对齐值的整数 倍，结合下面例子理解)。这样就不能理解上面的几个例子的值了。
例子分析：
分析例子B；
struct B
{
    char b;
    int a;
    short c;
};
假 设B从地址空间0x0000开始排放。该例子中没有定义指定对齐值，在笔者环境下，该值默认为4。第一个成员变量b的自身对齐值是1，比指定或者默认指定 对齐值4小，所以其有效对齐值为1，所以其存放地址0x0000符合0x0000%1=0.第二个成员变量a，其自身对齐值为4，所以有效对齐值也为4， 所以只能存放在起始地址为0x0004到0x0007这四个连续的字节空间中，复核0x0004%4=0,且紧靠第一个变量。第三个变量c,自身对齐值为 2，所以有效对齐值也是2，可以存放在0x0008到0x0009这两个字节空间中，符合0x0008%2=0。所以从0x0000到0x0009存放的 都是B内容。再看数据结构B的自身对齐值为其变量中最大对齐值(这里是b）所以就是4，所以结构体的有效对齐值也是4。根据结构体圆整的要求， 0x0009到0x0000=10字节，（10＋2）％4＝0。所以0x0000A到0x000B也为结构体B所占用。故B从0x0000到0x000B 共有12个字节,sizeof(struct B)=12;其实如果就这一个就来说它已将满足字节对齐了, 因为它的起始地址是0,因此肯定是对齐的,之所以在后面补充2个字节,是因为编译器为了实现结构数组的存取效率,试想如果我们定义了一个结构B的数组,那 么第一个结构起始地址是0没有问题,但是第二个结构呢?按照数组的定义,数组中所有元素都是紧挨着的,如果我们不把结构的大小补充为4的整数倍,那么下一 个结构的起始地址将是0x0000A,这显然不能满足结构的地址对齐了,因此我们要把结构补充成有效对齐大小的整数倍.其实诸如:对于char型数据，其 自身对齐值为1，对于short型为2，对于int,float,double类型，其自身对齐值为4，这些已有类型的自身对齐值也是基于数组考虑的,只 是因为这些类型的长度已知了,所以他们的自身对齐值也就已知了.
同理,分析上面例子C：
#pragma pack (2) /*指定按2字节对齐*/
struct C
{
    char b;
    int a;
    short c;
};
#pragma pack () /*取消指定对齐，恢复缺省对齐*/
第 一个变量b的自身对齐值为1，指定对齐值为2，所以，其有效对齐值为1，假设C从0x0000开始，那么b存放在0x0000，符合0x0000%1= 0;第二个变量，自身对齐值为4，指定对齐值为2，所以有效对齐值为2，所以顺序存放在0x0002、0x0003、0x0004、0x0005四个连续 字节中，符合0x0002%2=0。第三个变量c的自身对齐值为2，所以有效对齐值为2，顺序存放
在0x0006、0x0007中，符合 0x0006%2=0。所以从0x0000到0x00007共八字节存放的是C的变量。又C的自身对齐值为4，所以C的有效对齐值为2。又8%2=0,C 只占用0x0000到0x0007的八个字节。所以sizeof(struct C)=8.

四.如何修改编译器的默认对齐值?
1.在VC IDE中，可以这样修改：[Project]|[Settings],c/c++选项卡Category的Code Generation选项的Struct Member Alignment中修改，默认是8字节。
2.在编码时，可以这样动态修改：#pragma pack .注意:是pragma而不是progma.

五.针对字节对齐,我们在编程中如何考虑?

    如果在编程的时候要考虑节约空间的话,那么我们只需要假定结构的首地址是0,然后各个变量按照上面的原则进行排列即可,基本的原则就是把结构中的变量按照 类型大小从小到大声明,尽量减少中间的填补空间.还有一种就是为了以空间换取时间的效率,我们显示的进行填补空间进行对齐,比如:有一种使用空间换时间做 法是显式的插入reserved成员：
         struct A{
           char a;
           char reserved[3];//使用空间换时间
           int b;
}

reserved成员对我们的程序没有什么意义,它只是起到填补空间以达到字节对齐的目的,当然即使不加这个成员通常编译器也会给我们自动填补对齐,我们自己加上它只是起到显式的提醒作用.

六.字节对齐可能带来的隐患:
    代码中关于对齐的隐患，很多是隐式的。比如在强制类型转换的时候。例如：
unsigned int i = 0x12345678;
unsigned char *p=NULL;
unsigned short *p1=NULL;

p=&i;
*p=0x00;
p1=(unsigned short *)(p+1);
*p1=0x0000;
最后两句代码，从奇数边界去访问unsignedshort型变量，显然不符合对齐的规定。
在x86上，类似的操作只会影响效率，但是在MIPS或者sparc上，可能就是一个error,因为它们要求必须字节对齐.

七.如何查找与字节对齐方面的问题:
如果出现对齐或者赋值问题首先查看
1. 编译器的big little端设置
2. 看这种体系本身是否支持非对齐访问
3. 如果支持看设置了对齐与否,如果没有则看访问时需要加某些特殊的修饰来标志其特殊访问操作。

八.相关文章:转自http://blog.csdn.net/goodluckyxl/archive/2005/10/17/506827.aspx

 ARM下的对齐处理
from DUI0067D_ADS1_2_CompLib

3.13 type  qulifiers

有部分摘自ARM编译器文档对齐部分

对齐的使用:
1.__align(num)
   这个用于修改最高级别对象的字节边界。在汇编中使用LDRD或者STRD时
   就要用到此命令__align(8)进行修饰限制。来保证数据对象是相应对齐。
   这个修饰对象的命令最大是8个字节限制,可以让2字节的对象进行4字节
   对齐,但是不能让4字节的对象2字节对齐。
   __align是存储类修改,他只修饰最高级类型对象不能用于结构或者函数对象。
  
2.__packed
  __packed是进行一字节对齐
  1.不能对packed的对象进行对齐
  2.所有对象的读写访问都进行非对齐访问
  3.float及包含float的结构联合及未用__packed的对象将不能字节对齐
  4.__packed对局部整形变量无影响
  5.强制由unpacked对象向packed对象转化是未定义,整形指针可以合法定
  义为packed。
     __packed int* p;  //__packed int 则没有意义
  6.对齐或非对齐读写访问带来问题
  __packed struct STRUCT_TEST
 {
  char a;
  int b;
  char c;
 }  ;    //定义如下结构此时b的起始地址一定是不对齐的
         //在栈中访问b可能有问题,因为栈上数据肯定是对齐访问[from CL]
//将下面变量定义成全局静态不在栈上
static char* p;
static struct STRUCT_TEST a;
void Main()
{
 __packed int* q;  //此时定义成__packed来修饰当前q指向为非对齐的数据地址下面的访问则可以

 p = (char*)&a;         
 q = (int*)(p+1);     
 
 *q = 0x87654321;
/*  
得到赋值的汇编指令很清楚
ldr      r5,0x20001590 ; = #0x12345678
[0xe1a00005]   mov      r0,r5
[0xeb0000b0]   bl       __rt_uwrite4  //在此处调用一个写4byte的操作函数
     
[0xe5c10000]   strb     r0,[r1,#0]   //函数进行4次strb操作然后返回保证了数据正确的访问
[0xe1a02420]   mov      r2,r0,lsr #8
[0xe5c12001]   strb     r2,[r1,#1]
[0xe1a02820]   mov      r2,r0,lsr #16
[0xe5c12002]   strb     r2,[r1,#2]
[0xe1a02c20]   mov      r2,r0,lsr #24
[0xe5c12003]   strb     r2,[r1,#3]
[0xe1a0f00e]   mov      pc,r14
*/

/*
如果q没有加__packed修饰则汇编出来指令是这样直接会导致奇地址处访问失败
[0xe59f2018]   ldr      r2,0x20001594 ; = #0x87654321
[0xe5812000]   str      r2,[r1,#0]
*/

//这样可以很清楚的看到非对齐访问是如何产生错误的
//以及如何消除非对齐访问带来问题
//也可以看到非对齐访问和对齐访问的指令差异导致效率问题
}
 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/jszj/archive/2009/02/20/3915328.aspx

下面对于微软对于c++语言的修改做一下分析！

Lambda表达式

  很多编程编程语言都支持匿名函数(anonymous function)。所谓匿名函数，就是这个函数只有函数体，而没有函数名。Lambda表达式就是实现匿名函数的一种编程技巧，它为编写匿名函数提供了简明的函数式的句法。同样是Visual Studio中的开发语言，Visual Basic和Visual C#早就实现了对Lambda表达式的支持，终于Visual C++这次也不甘落后，在Visual Studio 2010中添加了对Lambda表达式的支持。
  Lambda表达式使得函数可以在使用的地方定义，并且可以在Lambda函数中使用Lambda函数之外的数据。这就为针对集合操作带来了很大的便利。在作用上，Lambda表达式类似于函数指针和函数对象，Lambda表达式很好地兼顾了函数指针和函数对象的优点，却没有它们的缺点。相对于函数指针或是函数对象复杂的语法形式，Lambda表达式使用非常简单的语法就可以实现同样的功能，降低了Lambda表达式的学习难度，避免了使用复杂的函数对象或是函数指针所带来的错误。我们可以看一个实际的例子：

view plaincopy to clipboardprint?
·········10········20········30········40········50········60········70········80········90········100·······110·······120·······130·······140·······150
#include "stdafx.h"  
#include <algorithm>  
#include <iostream>  
#include <ostream>  
#include <vector>  
 
using namespace std;  
 
int _tmain(int argc, _TCHAR* argv[])  
{  
    vector<int> v;  
    for (int i = 0; i < 10; ++i) {  
        v.push_back(i);  
    }  
         for_each(v.begin(), v.end(), [] (int n) {  
        cout << n;  
        if (n % 2 == 0) {  
            cout << " even ";  
        } else {  
            cout << " odd ";  
        }  
    });  
    cout << endl;  
 
    return 0;  
} 
#include "stdafx.h"
#include <algorithm>
#include <iostream>
#include <ostream>
#include <vector>

using namespace std;

int _tmain(int argc, _TCHAR* argv[])
{
    vector<int> v;
    for (int i = 0; i < 10; ++i) {
        v.push_back(i);
    }
         for_each(v.begin(), v.end(), [] (int n) {
        cout << n;
        if (n % 2 == 0) {
            cout << " even ";
        } else {
            cout << " odd ";
        }
    });
    cout << endl;

    return 0;
}
 

  这段代码循环遍历输出vector中的每一个数，并判断这个数是奇数还是偶数。我们可以随时修改Lambda表达式而改变这个匿名函数的实现，修改对集合的操作。在这段代码中，C++使用一对中括号“[]”来表示Lambda表达式的开始，其后的”(int n)”表示Lambda表达式的参数。这些参数将在Lambda表达式中使用到。为了体会Lambda表达式的简洁，我们来看看同样的功能，如何使用函数对象实现：
 
view plaincopy to clipboardprint?
·········10········20········30········40········50········60········70········80········90········100·······110·······120·······130·······140·······150
#include "stdafx.h"  
#include <algorithm>  
#include <iostream>  
#include <ostream>  
#include <vector>  
using namespace std;  
 
struct LambdaFunctor {  
    void operator()(int n) const {  
        cout << n << " ";  
        if (n % 2 == 0) {  
            cout << " even ";  
        } else {  
            cout << " odd ";  
        }  
 
    }  
};  
 
int _tmain(int argc, _TCHAR* argv[])  
{  
    vector<int> v;  
 
    for (int i = 0; i < 10; ++i) {  
        v.push_back(i);  
    }  
 
    for_each(v.begin(), v.end(), LambdaFunctor());  
    cout << endl;  
 
    return 0;  
} 
#include "stdafx.h"
#include <algorithm>
#include <iostream>
#include <ostream>
#include <vector>
using namespace std;

struct LambdaFunctor {
    void operator()(int n) const {
        cout << n << " ";
        if (n % 2 == 0) {
            cout << " even ";
        } else {
            cout << " odd ";
        }

    }
};

int _tmain(int argc, _TCHAR* argv[])
{
    vector<int> v;

    for (int i = 0; i < 10; ++i) {
        v.push_back(i);
    }

    for_each(v.begin(), v.end(), LambdaFunctor());
    cout << endl;

    return 0;
}
 
  通过比较我们就可以发现，Lambda表达式的语法更加简洁，使用起来更加简单高效

静态断言static_assert

  在之前的C++标准C++03中，我们可以使用两种断言：
  • 使用预处理中的条件编译和#error指令，可以在预处理阶段检查一些编译条件
  • 可以使用宏assert来进行运行时检查，以确保程序逻辑的正确性

  但使用#error方法是非常烦琐的，并且不能够对模板参数进行检查，因为模板实例化是在编译时进行，而#error方法是在预处理阶段进行的。而assert宏是在运行时进行检查。不难发现，我们缺少了一样东西，那就是可用于在编译时检查的工具。于是，静态断言应运而生。

  在新的C++标准C++0x中，加入了对静态断言的支持，引入了新的关键字static_assert来表示静态断言。使用静态断言，我们可以在程序的编译时期检测一些条件是否成立，这个特性在调试模板函数的模板参数时特别有用。在编译的时候，模板函数实例化，这时我们就可以使用静态断言去测试模板函数的参数是否按照我们的设计拥有合适的值。例如下面这段代码：

view plaincopy to clipboardprint?
·········10········20········30········40········50········60········70········80········90········100·······110·······120·······130·······140·······150
template <int N> struct Kitten {  
    static_assert(N < 2, "Kitten<N> requires N < 2.");  
};  
 
int main() {  
    Kitten<1> peppermint;  
    Kitten<3> jazz;  
 
   return 0;  
} 
template <int N> struct Kitten {
    static_assert(N < 2, "Kitten<N> requires N < 2.");
};

int main() {
    Kitten<1> peppermint;
    Kitten<3> jazz;

   return 0;
}
 
  当我们在主函数中使用“1”去实例化Kitten这个结构体时，在编译的时候，静态断言static_assert会测试参数N的值，当N的值小于2时就会产生一个断言错误，并将相应的调试帮助信息输出到“Error List”窗口中，这样程序员就可以对问题快速定位，解决问题就更加方便了。
 

图2 static_assert断言及其输出

  另外，静态断言还带来很多其他的优势。例如静态断言在编译时进行处理，不会产生任何运行时刻空间和时间上的开销，这就使得它比assert宏具有更好的效率。另外比较重要的一个特性是如果断言失败，它会产生有意义且充分的诊断信息，帮助程序员快速解决问题。

  auto关键字

  在C++0x中，auto关键字的意义发生了改变。从Visual C++ 2010开始，auto关键字将用于指引编译器根据变量的初始值来决定变量的数据类型。换句话说，我们可以把auto当成一种新的数据类型，它可以“从初始化器(initialize)中推导出所代表的变量的真正类型”。这种对auto关键字的使用方式可以大大消除当前替代方式所导致的冗长和易出错的代码。我们看一个实际的例子：

view plaincopy to clipboardprint?
·········10········20········30········40········50········60········70········80········90········100·······110·······120·······130·······140·······150
#include <iostream>  
#include <map>  
#include <ostream>  
#include <regex>  
#include <string>  
using namespace std;  
using namespace std::tr1;  
 
int main() {  
    map<string, string> m;  
 
    const regex r("(\\w+) (\\w+)");  
 
    for (string s; getline(cin, s); ) {  
        smatch results;  
        if (regex_match(s, results, r)) {  
            m[results[1]] = results[2];  
        }  
    }  
    for (auto i = m.begin(); i != m.end(); ++i) {  
        cout << i->second << " are " << i->first << endl;  
    }  
 
    return 0;  
} 
#include <iostream>
#include <map>
#include <ostream>
#include <regex>
#include <string>
using namespace std;
using namespace std::tr1;

int main() {
    map<string, string> m;

    const regex r("(\\w+) (\\w+)");

    for (string s; getline(cin, s); ) {
        smatch results;
        if (regex_match(s, results, r)) {
            m[results[1]] = results[2];
        }
    }
    for (auto i = m.begin(); i != m.end(); ++i) {
        cout << i->second << " are " << i->first << endl;
    }

    return 0;
}
 
  在这段代码中，我们使用auto关键字来代替了真正的数据类型map<string, string>::iterator，这使得整个代码自然而简洁。

  另外，跟其他数据类型一样，我们也可以对auto关键字进行修饰，例如添加const，指针(*)，左值引用(&)，右值引用(&&)等等，编译器会根据auto类型所代表的真正的数据来决定这些修饰的具体含义。

  为了兼容一些旧有的C++代码，我们可以使用/Zc:auto这个编译器选项，来告诉编译器是采用auto关键字的原有定义还是在新标准C++0x中的定义。

右值引用

  作为最重要的一项语言特性，右值引用(rvalue references)被引入到 C++0x中。我们可以通过操作符“&&”来声明一个右值引用，原先在C++中使用“&”操作符声明的引用现在被称为左值引用。

int a;
int& a_lvref = a;  // 左值引用

int b;
int&& b_rvref = b;  // 右值应用
  左值引用和右值引用的表现行为基本一致，它们唯一的差别就是右值引用可以绑定到一个临时对象(右值)上，而左值引用不可以。例如：

int& a_lvref = int();      // error C2440: 'initializing' : cannot convert from 'int' to 'int &'   
int&& b_rvref = int();  // OK!
  在第一行代码中，我们将一个临时对象int()绑定到一个左值引用，将产生一个编译错误。而在第二行中，我们将临时对象绑定到右值引用，就可以顺利通过编译。

  右值是无名的数据，例如函数的返回值一般说来就是右值。当对右值进行操作的时候，右值本身往往没有必要保留，因此在某些情况下可以直接“移动”之。通过右值引用，程序可以明确的区分出传入的参数是否为右值，从而避免了不必要的拷贝，程序的效率也就得到了提高。我们考虑一个简单的数据交换的小程序，从中来体会右值引用所带来的效率提升。我们可以写一个函数swap来实现两个变量值的交换：

view plaincopy to clipboardprint?
·········10········20········30········40········50········60········70········80········90········100·······110·······120·······130·······140·······150
template <class T> swap(T& a, T& b)  
{  
    T tmp(a);   // tmp对象创建后，我们就拥有了a的两份拷贝  
    a = b;      // 现在我们拥有b的两份拷贝  
    b = tmp;    // 现在我们拥有a的两份拷贝  
} 
template <class T> swap(T& a, T& b)
{
    T tmp(a);   // tmp对象创建后，我们就拥有了a的两份拷贝
    a = b;      // 现在我们拥有b的两份拷贝
    b = tmp;    // 现在我们拥有a的两份拷贝
}
  在这段代码中，虽然我们只是为了进行简单的数据交换，但是却执行了多次对象拷贝。这些对象的拷贝操作，特别是当这些对象比较大的时候，无疑会影响程序的效率。

  那么，如果使用右值引用如何实现呢？

view plaincopy to clipboardprint?
·········10········20········30········40········50········60········70········80········90········100·······110·······120·······130·······140·······150
#include "stdafx.h"  
 
template <class T>   
T&& move(T&& a)  
{  
    return a;  
}  
 
template <class T> void swap(T& a, T& b)  
{  
    T tmp(move(a)); // 对象a被移动到对象tmp，a被清空  
    a = move(b);    // 对象b被移动到对象a，b被清空  
    b = move(tmp);  // 对象tmp被移动到对象b  
}  
 
int _tmain(int argc, _TCHAR* argv[])  
{  
    int a = 1;  
    int b = 2;  
    swap(a, b);  
 
   return 0;  
} 
#include "stdafx.h"

template <class T>
T&& move(T&& a)
{
    return a;
}

template <class T> void swap(T& a, T& b)
{
    T tmp(move(a)); // 对象a被移动到对象tmp，a被清空
    a = move(b);    // 对象b被移动到对象a，b被清空
    b = move(tmp);  // 对象tmp被移动到对象b
}

int _tmain(int argc, _TCHAR* argv[])
{
    int a = 1;
    int b = 2;
    swap(a, b);

   return 0;
}
 

  在这段重新实现的代码中，我们使用了一个move()函数来代替对象的赋值操作符“=”,move()只是简单地接受一个右值引用或者左值引用作为参数，然后直接返回相应对象的右值引用。这一过程不会产生拷贝(Copy)操作，而只会将源对象移动(Move)到目标对象。

  正是拷贝(Copy)和移动(Move)的差别，使得右值引用成为C++0x中最激动人心的新特性之一。从实践角度讲，它能够完美是解决C++中长久以来为人所诟病的临时对象的效率问题。从语言本身讲，它健全了C++中的引用类型在左值右值方面的缺陷。从库设计者的角度讲，它给库设计者又带来了一把利器。而对于广大的库使用者而言，不动一兵一卒便能够获得“免费的”效率提升。

  在Visual Studio 2010中，因为有了对这些C++0x新特性的支持，重新点燃了程序员们对C++的热情。C++重振雄风，指日可待！

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/yincheng01/archive/2010/03/11/5367032.aspx

内存管理是C++程序员的痛。我的《内存管理变革》系列就是试图讨论更为有效的内存管理方式，以杜绝（或减少）内存泄漏，减轻C++程序员的负担。由于工作忙的缘故，这个系列目前未完，暂停。
 
这篇短文我想换个方式，讨论一下如何以最快的速度找到内存泄漏。
 
确认是否存在内存泄漏
我们知道，MFC程序如果检测到存在内存泄漏，退出程序的时候会在调试窗口提醒内存泄漏。例如：

class CMyApp : public CWinApp
{
public:
   BOOL InitApplication()
   {
       int* leak = new int[10];
       return TRUE;
   }
};
产生的内存泄漏报告大体如下：

Detected memory leaks!
Dumping objects ->
c:\work\test.cpp(186) : {52} normal block at 0x003C4410, 40 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
这挺好。问题是，如果我们不喜欢MFC，那么难道就没有办法？或者自己做？

呵呵，这不需要。其实，MFC也没有自己做。内存泄漏检测的工作是VC++的C运行库做的。也就是说，只要你是VC++程序员，都可以很方便地检测内存泄漏。我们还是给个样例：

#include <crtdbg.h>

inline void EnableMemLeakCheck()
{
   _CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);
}

void main()
{
   EnableMemLeakCheck();
   int* leak = new int[10];
}
 运行（提醒：不要按Ctrl+F5，按F5），你将发现，产生的内存泄漏报告与MFC类似，但有细节不同，如下：

Detected memory leaks!
Dumping objects ->
{52} normal block at 0x003C4410, 40 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
为什么呢？看下面。

定位内存泄漏由于哪一句话引起的
你已经发现程序存在内存泄漏。现在的问题是，我们要找泄漏的根源。

一般我们首先确定内存泄漏是由于哪一句引起。在MFC中，这一点很容易。你双击内存泄漏报告的文字，或者在Debug窗口中按F4，IDE就帮你定位到申请该内存块的地方。对于上例，也就是这一句：

   int* leak = new int[10];

这多多少少对你分析内存泄漏有点帮助。特别地，如果这个new仅对应一条delete（或者你把delete漏写），这将很快可以确认问题的症结。

我们前面已经看到，不使用MFC的时候，生成的内存泄漏报告与MFC不同，而且你立刻发现按F4不灵。那么难道MFC做了什么手脚？

其实不是，我们来模拟下MFC做的事情。看下例：

inline void EnableMemLeakCheck()
{
   _CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);
}

#ifdef _DEBUG
#define new   new(_NORMAL_BLOCK, __FILE__, __LINE__)
#endif

void main()
{
   EnableMemLeakCheck();
   int* leak = new int[10];
}

再运行这个样例，你惊喜地发现，现在内存泄漏报告和MFC没有任何分别了。

快速找到内存泄漏
单确定了内存泄漏发生在哪一行，有时候并不足够。特别是同一个new对应有多处释放的情形。在实际的工程中，以下两种情况很典型：

创建对象的地方是一个类工厂（ClassFactory）模式。很多甚至全部类实例由同一个new创建。对于此，定位到了new出对象的所在行基本没有多大帮助。
 
COM对象。我们知道COM对象采用Reference Count维护生命周期。也就是说，对象new的地方只有一个，但是Release的地方很多，你要一个个排除。
那么，有什么好办法，可以迅速定位内存泄漏？

答：有。

在内存泄漏情况复杂的时候，你可以用以下方法定位内存泄漏。这是我个人认为通用的内存泄漏追踪方法中最有效的手段。

我们再回头看看crtdbg生成的内存泄漏报告：

Detected memory leaks!
Dumping objects ->
c:\work\test.cpp(186) : {52} normal block at 0x003C4410, 40 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
除了产生该内存泄漏的内存分配语句所在的文件名、行号为，我们注意到有一个比较陌生的信息：{52}。这个整数值代表了什么意思呢？

其实，它代表了第几次内存分配操作。象这个例子，{52}代表了第52次内存分配操作发生了泄漏。你可能要说，我只new过一次，怎么会是第52次？这很容易理解，其他的内存申请操作在C的初始化过程调用的呗。:)

有没有可能，我们让程序运行到第52次内存分配操作的时候，自动停下来，进入调试状态？所幸，crtdbg确实提供了这样的函数：即 long _CrtSetBreakAlloc(long nAllocID)。我们加上它：

inline void EnableMemLeakCheck()
{
   _CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);
}

#ifdef _DEBUG
#define new   new(_NORMAL_BLOCK, __FILE__, __LINE__)
#endif

void main()
{
   EnableMemLeakCheck();
   _CrtSetBreakAlloc(52);
   int* leak = new int[10];
}
你发现，程序运行到 int* leak = new int[10]; 一句时，自动停下来进入调试状态。细细体会一下，你可以发现，这种方式你获得的信息远比在程序退出时获得文件名及行号有价值得多。因为报告泄漏文件名及行号，你获得的只是静态的信息，然而_CrtSetBreakAlloc则是把整个现场恢复，你可以通过对函数调用栈分析（我发现很多人不习惯看函数调用栈，如果你属于这种情况，我强烈推荐你去补上这一课，因为它太重要了）以及其他在线调试技巧，来分析产生内存泄漏的原因。通常情况下，这种分析方法可以在5分钟内找到肇事者。

当然，_CrtSetBreakAlloc要求你的程序执行过程是可还原的（多次执行过程的内存分配顺序不会发生变化）。这个假设在多数情况下成立。不过，在多线程的情况下，这一点有时难以保证。

附加说明：
对“内存管理”相关的技术感兴趣？这里可以看到我的所有关于内存管理的文章。

本文来自CSDN博客，转载请标明出处： http://blog.csdn.net/i_like_cpp/archive/2007/06/28/1669962.aspx