编写易于调试的VC代码(转载)
提供者：bluejoe 张贴时间：2007-01-23 17:00:05.0 出处：csdn.net 作者：michael 

一 程序的设计

　　要避免错误，首先要从好的设计开始。对于程序的设计，需考虑到程序的两个特性：

　　1简单性

　　大多数常见的错误来源于程序设计中不必要的复杂成分。一个好的设计应该反映问题本身的要求，而不必为了刻意追求“满足将来的需要”而添加不必要的特性。实际上，简单优雅的设计比那些复杂的设计更能迎合未来的需求。

　　2 耦合性

　　耦合(decoupling)性用来衡量不同对象之间的依赖程度。松耦合的程序易于理解和实现，易于测试和维护，且这种程序包含错误的可能性小，错误也较容易发现和清除。
 

二 编程风格

　　编程风格是个人问题，有很大的随意性。一个好的编程风格不仅让代码易理解，也易于调试。好的编程风格包括：

　　1 清晰地书写代码

　　如果没有必要，尽量不要使用语言中的高级特性，因为这些特性不易于理解和调试。使用大多数程序员都能理解的语言成分来书写代码不易犯错且易于理解和维护。

　　2 编写结构良好的代码

　　当程序崩溃时所能得到的最基本的调试信息是源代码文件、问题所在行的行号和一个调用栈(call stack)。调用栈是调试程序时最有帮助的部分，它提供错误出现的上下文，也就是带参数的函数调用序列。你书写的代码结构越好，调用栈就能给你越多信息。

　　3 使用良好的标识符

　 　一个好名字能使你的代码更容易被理解和维护。流行的匈牙利命名法(Hungarian Notation)实际上是把标识符的意义和表示方法结合起来。 现在，匈牙利命名法表现出不少的局限性，匈牙利命名法过于看重前缀的作用，对一个变量的表达信息不完整，实际上并没有传递多少有用信息，它使代码难于阅 读，难以维护。一个好的命名传统是指示出变量的作用域以便在需要的时候检查它的定义，并明确地指出一个变量是全局的、局部的还是成员数据。依赖变量的定义 比依赖匈牙利前缀更加有用和可靠。

　　好的名字能够用平常的语言概括出该标识符所代表的实体的含义。在选择类、函数、变量的名字时可以考虑以下几个原则：

　　　　取简单的描述性名字，好的名字能简要地概括出这个标识符代表的含义。

　　　　避免简写，简写使标识符难于阅读和记忆，尽量使用混合大小写的完整的单词。

　　　　避免相似性的文字，避免混淆。

　　　　避免采用一般的或随机产生的名字，而应采用有实际意义的名字。如欲从按钮类派生位图按钮，取一个CBitmapButton，而不是CMyButton。

　　4 用简单的语句行

　　在VC中，一行可写多个语句。但调试是面向行的，过于复杂的行难于调试。因此，从调试的角度出发，每一个语句都应独自成行。

　　5 使用统一的排列

　　统一的排列方式使类、变量的定义和语句更加明显。

　　6 用括号使书写清晰

　　你不一定能都记住各种运算符的优先级和结合律，而使用多余的括号并不影响编译后的代码。因此，如果你不能确定是否需要括号时，请加上它。

　　7 使用好的注释

　　用好的注释能使你的代码不易出错，而且便于其他程序员阅读，便于理解和维护。

三 编写程序时应注意的问题

　　1 充分利用VC++的特性

　　可用下列技术来充分利用VC++的编译器的特性：

　　（1）用const代替#define来创建常量；

　　（2）用enum代替#define来创建常量集合；

　　（3）用内联(inline)函数代替#define；

　 　这三种技术用C++而不是C预处理。使用预处理的问题在于编译器对于预处理器所作的事情一无所知，因此无法用数据类型检查错误和不一致的地方。预处理的 名字不在符号表里，因此也不能用调试工具来检查预处理常量。相似地，预处理宏被编译进去，不能用调试工具跟踪。编译器能充分了解const、enum和 inline语句，从而能在编译的时候对出现的问题发出警告。

　　但预处理在很多调试代码中起重要作用。调试代码经常需要从非调试代码里面得到不同的行为，而最有效的办法就是让预处理为调试创建不同的代码。

　　（4）用new和delete代替malloc和free;

　　在创建对象、类型的安全性和灵活性方面。使用new/delete比malloc/free要好。另外，new可被重载，提供了更大的灵活性。

　　（5）用输入输出流(iostreams)代替stdio。

　 　使用C++输入输出流（<<和>>）而不使用C标准输入输出库（printf/sprintf和scanf/sscanf）， 有利于安全性和扩展性。从调试的角度来看，标准输入输出函数的最大问题在于编译器不能对控制流参数进行任何类型检测，而输入输出流的任何问题都能在编译时 检测出来。

　　2 使用头文件

　　要在头文件中声明所有共享的外部符号，而且保留函数原型中的参数名。把所有的共享定义放在头文件中，不要在.cpp文件里面看到extern关键字。

　　3 初始化变量

　 　在使用变量之前一定要把它们初始化。在初始化之前就使用变量肯定会产生错误。通常不需对对象进行初始化，对对数据成员应在构造函数中初始化。必须明确地 为在栈中和堆中分配的数组和数据结构进行初始化。对于对象，应该初始化每个需要初始化的数据成员。因为变量的使用是由优化器来检查的，所以检测未初始化的 本地变量，发布版本要比调试版本要做得好。

　　4 使用布尔表达式

C++的布尔类型：bool，值为true和false，大小为一个字节。

Windows程序通常用BOOL类型。定义如下：

1Typedef int BOOL;    
2  
3#define FALSE 0    
4  
5#define TRUE 1   

在C++中，一个布尔表达式如果为0则为假，其他则为真。因此，对布尔表达式应该检查是否问假而不是检查是否为真。

　　5 使用句柄和指针

　　初始化一个指针时，要么让其指向一个有效的内存地址，要么设为0（空指针），避免指针指向无效地址。回收指针所指对象时要重新初始化这个指针，并且在指针被释放前为空时就对其进行处理。对句柄的处理跟指针一样。

　　6 用引用而不是指针做参数

　　用指针做函数的参数可传递一个空指针，很灵活，但也很容易忘了对指针进行初始化。而引用是对象的别名，它必须和有效的对象相关联，不存在空的和没有初始化的引用。当在函数中收到一个引用参数时，可以肯定这是一个有效的对象。程序用引用做参数比用指针做参数更为健壮。

　　7 强制类型转换(cast)

　 　进行数据类型的强制类型转换时，将会调用相应的构造函数或转换函数来创建一个新类型的临时对象。对指针的正确类型转换可消除一个编译错误，但并没改变指 针。强制类型转换破坏了编译器进行类型检查的功能，而这正是编译器查找错误的最有效的机制。为了保证安全性，每一个强制类型转换都需要手工进行类型检查。 为尽量避免强制类型转换，你可以：避免使用多态数据类型；使用更加广泛的基类；提供特殊的存取函数；让编译器隐式处理类型转换等措施。

　　8 使用构造函数和析构函数

　 　构造函数需要分配内存，创建资源或者打开文件，这些运算并不总是成功。构造函数没有返回值，没有直接显示错误的方法。一个常见的方法（在很多MFC类中 使用）是把对象创建分为两步：第一步，让构造函数以一种不会出错的方式初始化对象；第二步，让某些初始化函数（如Init或Open）完成工作，这一步可 能出错。另一种方法是在构造函数中使用异常：第一步，以不会出错的方式初始化对象；第二步，用可能在try段内出错的代码初始化对象；第三步，在 catch代码里面处理异常。如果出现异常，就会在构造函数里清除分配的资源，并且再次抛出异常。

　　异常处理的一个关键细节就是在栈展 开的过程中抛出的异常会终止整个应用程序。在处理异常时经常要调用析构函数，因此析构函数很容易出错，一定要保证析构函数的异常在析构函数中得到处理。要 保证基类的析构函数是虚函数。这样，就算对象是一个指向基类的指针，也会调用派生类的析构函数。否则，就会引起资源泄漏(resource leak)。  

在VC程序中使用调试语句

为了更好地对程序调试，可以使用如下方法：使用断言、使用跟踪语句、使用异常和返回值。

一、断言

1、基本概念

　　断言是一种让错误在运行时候自我暴露的简单有效实用的技术。它们帮助你较早较轻易地发现错误，使得整个调试过程效率更高。

　　断言是布尔调试语句，用来检测在程序正常运行的时候某一个条件的值是否总为真，它能让错误在运行时刻暴露在程序员面前。使用断言的最大好处在于，能在更解决错误的发源地的地方发现错误。断言具有以下特征：

.断言是用来发现运行时刻错误的，发现的错误是关于程序实现方面的。

.断言中的布尔表达式显示的是某个对象或者状态的有效性而不是正确性。

.断言在条件编译后只存在于调试版本中，而不是发布版本里。

.断言不能包含程序代码。

.断言是为了给程序员而不是用户提供信息。

　 　使用断言最根本的好处是自动发现许多运行时产生的错误，但断言不能发现所有错误。断言检查的是程序的有效性而不是正确性，可通过断言把错误限制在一个有 限的范围内。当断言为假，激活调试器显示出错代码时，可用Call Stack命令，通过检查栈里的调用上下文、少量相关参数的值以及输出窗口中 Debug表的内容，通常能检查出导致断言失败的原因。_ASSERTE宏(属于C运行时间库)还能在断言失败时显示出失效断言。下面我们讨论一下MFC 库中的断言。

2、MFC库中的断言

(1) ASSERT(布尔表达式)

用MFC时最好选择ASSERT宏，它的优点是即使出现了WM_QUIT消息也能显示断言失效消息框。

(2) VERIFY(布尔表达式)

VERIFY 宏中的布尔表达式在发布版本中被保留下来。VERIFY宏简化了对函数返回值的检查，一般用来检查Windows API的返回值。由于 VERIFY宏里的布尔表达式在发布版本里保留了下来，因此最好尽量不要使用这个宏以实现程序代码和调试代码的完全分离。

(3 )ASSERT_VALID(指向CObject派生类对象的指针)

ASSERT_VALID宏通过调用重载的AssertValid函数来确定指向CObject派生类对象的指针是否有效。无论你什么时候从CObject派生类中得到一个对象，在对这个对象做任何操作之前都应该调用ASSERT_VALID宏。

(4) ASSERT_KINDOF(类名, 指向CObject派生类对象的指针)

这个宏用来验证指向CObject派生类对象的指针是否从某个特殊类中派生，在调用它之前先调用ASSERT_VALID宏。只有在很特殊的场合下才用得到，如检测编译器可能错过的对象类型问题。

此外，还有两个没有正式文件的ASSERT宏的变种：ASSERT_POINTER(指针,指针类型)，ASSERT_NULL_OR_POINTER(指针,指针类型)。

3、什么时候使用断言

　　把断言看作一种简单的制造栅栏的方法，这种栅栏能使错误在穿过自己时暴露。

.检查函数的输入

.检查函数的输出

.检查对象的当前状态

.坚持逻辑变量的合理性和一致性

.检查类中的不变量

公有成员函数比私有和保护的成员函数需要更全面的断言。

　　不正确地使用断言会导致错误。断言应该检测那些在程序正常运行的时候永远都不可能出现的状态。断言是用来揭示错误的，而不是用来纠正运行时刻错误的。

4、断言与防御性编程(Defensive Programming)

　 　断言在调试的时候向程序员揭示运行时刻错误（调试版本里），而防御性编程使用户在运行程序（发布版本里）时，当出现意外情况时程序仍能继续工作。实际 上，防御性的编程要求程序在检测到意外时返回一个“安全”的值（比如布尔函数返回false，指针和句柄返回空值），一个错误代码或者抛出一个异常来解决 问题。特定的防御性编程技术包括：处理无效函数参数和数据、出现问题的时候程序失败、检查临界函数返回的错误代码以及处理异常。需要防御性编程的标准问题 包括：错误的输入数据、内存或者硬盘空间不够、不能打开一个文件、外部设备不能访问、网络连接不上或者甚至在程序中还有错误，目的是保持程序的运行状态。 如果你的程序是防御性的，别忘了使用断言。如果你使用断言，也别忘了防御性编程。这两种技术最好结合在一起使用。

二、跟踪语句

1、基本概念

　 　跟踪语句(trace statements)可使程序执行，并使程序员可对可变值进行查看。它们提供了一个用于观察的程序，并且独立于一个交互式的调 试器，但是最具有特色的是它们常用于对调试器提供的信息进行补充。在VC中，跟踪消息通常输出到输出窗口中的Debug标签，也可以重新输出到一个文件 中。跟踪语句的特性如下：

.跟踪语句用于报告代码中重要的运行事件。

.跟踪语句的编译通常是有条件的，并只存在于调试版本中，而在发布版本中不被编译。

.跟踪语句不能包含程序代码或对程序代码有间接的影响作用。

.跟踪语句的目的是向程序员提供信息，而不是向用户。

跟踪语句也是调试语句，它可以执行程序，并且在运行中程序员可以查看变量。跟踪语句对于那些使用交互式调试器很难调试的程序是很有效的。

跟踪语句和断言的区别如下：

.跟踪语句是无条件的，断言是有条件的布尔语句。

.跟踪语句用于显示程序执行和变量值，不直接显示bug，断言用于显示出bug。

.跟踪语句将信息输出到调试窗口或文件中，可被随意地忽略，断言打断程序的执行。

2、MFC中的跟踪语句

　 　在MFC中，你可以使用TRACE和AfxOutputDebugString宏、CObject::Dump虚拟函数和AfxDumpStack函 数。TRACE宏由AfxDump实现，AfxDump由AfxOutputDebugString实现。AfxOutputDebugString宏和 AfxDumpStack函数可以在所有版本中编译，其他只能在调试版本中编译。


（1）TRACE宏有以下形式：

1_TRACE(reportType,format);    
2  
3_TRACE0(reportType,format,arg1);    
4  
5_TRACE1(reportType,format,arg1,arg2);    
6  
7_TRACE2(reportType,format,arg1,arg2,arg3);    
8  
9_TRACE3(reportType,format,arg1,arg2,arg3,arg4);

使用Visual C++调试器调试

一、调试版本与发布版本

　　有时程序能在调试版本运行但不能运行于发布版本，反之也有可能。一般说来，一个发布版本意味着某些类型的优化，而一个调试版本则没有优化。下面我们来看看它们的区别：

1、特别针对调试版本的编译选项

（1）/MDd,/MLd或者/MTd

　　调试版本的运行时刻库有调试符号，使用了调试堆，调试堆的目的是发现内存破坏和内存泄漏，并且向用户报告源代码的哪个地方出了问题。特性：

.调试版本的运行时刻库对内存的分配作了跟踪，允许用户检查内存泄漏。

.在刚分配的内存里写上0xCD的字节模式，用0xCD来填充刚分配的内存，有助于发现数据未被初始化的错误。

.在被释放的内存写上0xDD的字节模式，有助于发现已被释放的内存。

.在缓冲区的两边分配了四字节的保护数据，并用0xFD的字节模式作初始化，来检查写内存的上溢出和下溢出。

.在每个内存分配的地方对源代码文件名和行号作了记录，有助于用户在源代码中对内存分配进行定位。

（2）/Od

　 　这个选项用来关闭优化开关。因为未被优化的代码直接对应于源代码，所以比优化后的代码更容易读懂。未被优化的代码编译和链接会更快，会有更短的调试周 期。而由于优化，发布版本不见得会比调试版本运行得好，优化代码要求编译器做一些假设，去除冗余，但有时这个假设是错误的，并且去掉的冗余也有可能隐藏错 误。如发布版本的帧指针（EBP寄存器）省略（FPO）隐藏了函数原型不匹配的错误；在同步异常模式（只能由throw语句抛出，编译器默认，由/GX编 译选项设置）下，异常处理程序可能被优化掉，会阻止程序中的C++异常处理代码安全地捕获结构异常，在这种情况下，你必须使用异步异常模式（采取任何指令 都会产生异常的机制，由/Eha编译选项设置）。

（3）/D “_DEBUG”

　　打开条件编译调试代码开关。只有这个符号被定义，调试代码才会被编译，MFC使用_DEBUG符号来确定到底链接的是哪个版本的MFC类库。在调试版本中，内联默认情况下是被关闭的。

（4）/ZI

　 　创建编辑继续(Edit and Continue)的程序数据库。这个选项会打开/GF编译选项，/GF编译选项会消除重复字符串，并将字符串放到只 读内存。编辑继续功能需要获取存储在PDB文件里的特殊信息来使得代码的修改对调试器有效。如果被修改文件对应的信息不在PDB文件里，编辑继续功能就不 能进行，而且在调试过程中对代码的任何修改都会出现下面的提示信息 “One or more files are out of date or do not exist.”。

（5）/GZ

在调试版本中用来发现那些在发布版本里才发现的错误。其作用如下：

.用0xCC模式初始化自动（本地）变量。

.在通过函数指针调用函数时，检查栈指针，确认是否有调用规则不匹配。

.在函数最后检查栈指针是否被改变。

（6）/Gm

　　打开最小化重新链接开关，减少链接时间。

2、特别针对发布版本的编译选项

（1）/MD,/ML或者/MT

　　使用发布版本的运行时刻库。

（2）/O1或者/O2

　　打开优化开关，使得程序会最小或说速度会最快，优化器还可能发现代码中潜在的错误，而这些错误可能会被调试版本掩盖。

（3）/D “NDEBUG”

　　关闭条件编译调试代码开关。

（4）/GF

　　消除重复字符串并将它们放到只读内存中以避免被错误地修改。

（5）/Zi

创建包含调试符号的程序数据库。

　 　如果一个错误只发生在发布版本里，除非你是个汇编高手，否则你需要调试符号来提示你到底程序出现了什么问题，调试符号保存在程序的数据库文件（PDB） 中。Visual C++的AppWizard默认情况下没有为发布版本创建调试符号。为创建调试符号，打开工程设置对话框，选择 Win32 Release，在C/C++标签里选择Common类，在调试信息里，如果是发布版本选择Program Database，如果是调试版 本选择Program Database for Edit and Continue（编辑继续选项与优化链接不相容，不适于发布版本）。在Link标 签里选择Debug类，然后选择Debug Info和Microsoft format选项，最好不要选择Separate types选项，这样所有 的调试信息才会被合并到单独的一个PDB文件中。对于发布版本，选择Link标签，在Project options对话框的最后加上“/OPT: REF”，这个选项使得不被引用的函数和数据不会出现在可执行文件中，避免了文件的无谓增大。对于调试版本不要使用这个选项，它会关闭增量链接 (incremental linking)。

二、Visual C++编辑器的“设置”菜单

　　当你打开或新建一个包 含至少一个工程的Workspace后，Visual C++的Project菜单中的“Settings…”命令就变为有效，选择它或者按下热键Alt +F7后，便可调出工程设置对话框，这里面的选项将影响整个工程的建立和调试过程，因此很重要。

　　在这个对话框中，左上方的下拉列表框 用于选择一种工程配置，包括有Win32 Debug、Win32 Release和All Configurations（指前两种配置一起），某些选 项在不同的工程配置中有不同的缺省值。左边的树形视图给出了当前工程所有的文件及分类情况。下面我们就以Win32 Debug为例来看看与工程有关的的 四个主要选项卡的各自功能与含义（一共有十个选项卡）：

1、 General选项卡

　　这个选项卡比较简单，从上向下的 第一个选项用于更改使用MFC类库的方式： DLL的方式或是静态连接。我们可以在两种方式之间进行切换。第二个选项用于指定在编译连接过程中生成的中间 文件和输出文件的存放目录，对于调试版本来说，缺省的目录是工程下面的“Debug”子目录。第三个选项用于指定是否允许每种工程配置都有自己的文件依赖 关系（主要指头文件），由于绝大多数工程的调试版本和发布版本都具有相同的文件依赖关系，所以通常不需要更改该选项。

2、 Debug选项卡

　　Debug选项卡中是一些与调试有关的选项，由于选项比较多，它们被分成了几个类，我们可以从Category中选择不同的类别，选项卡就会切换显示出相应的选项。

　　在General类别中，可以指定要调试的可执行文件名。另外三个选项可以指定用于调试的工作目录，开始调试时给程序传送的命令行参数，以及进行远程调试时可执行文件的路径。

3、C/C++选项卡

　 　C/C++选项卡控制着Visual C++的编译器，其中的选项比较多。下面有一个Project Options编辑框，里面 列出的各种命令开关将会在开始编译时作为命令行参数传送给Visual C++的编译器。这些命令开关会跟随其它选项改变而改变。

　 　在General类别中，Warning level用于指定编译器显示警告的级别，如果选中了Warnings as errors，那么显示的每一 个警告都将会引起一个错误，这样在编译完毕后就无法启动连接器来进行连接。Optimizations用于设置代码优化方式，优化的目的主要有提高运行速 度和减小程序体积两种，但有时候这两种目的是相互矛盾的。另外，在极少数情况下，不进行优化，程序能正常运行，打开了优化措施之后，程序却会出现一些莫名 其妙的问题。其实这多半是程序中有潜在的错误，关闭优化措施往往只是暂时解决问题。Debug info用于指定编译器产生的调试信息的类型，为了使用 Visual C++的即编即调功能，必须在这里选择生成“Program Database for Edit and Continue”类型的调试 信息。Preprocessor definitions是一些预先定义的宏名。

　　C++ Language类别中的选项涉及到了C+ +语言的一些高级特性，包括有成员指针的表示方式、异常处理、运行时类型信息，一般情况下都不用改变它们。Code Generation类别中的选项涉 及如何生成目标代码，一般情况下保持缺省值即可。在Customize类别中，从上到下六个选项的含义分别为：是否禁止使用Microsoft对C++的 扩展；是否允许函数级别的连接；是否消除重复的字符串；是否允许进行最小化的重建；是否允许递增编译方式；是否允许编译器在开始运行时向Output窗口 中输出自己的版本信息。

　　在Listing Files类别中，我们可以指定编译器生成浏览信息和列表文件 （Listing file），前者可由浏览信息维护工具BSCMAKE生成浏览信息文件，后者则包含了C/C++源文件经过编译后对应的汇编指令。 Optimizations类别允许我们对优化措施进行更细微的控制，选择了Customize后，便可以选择进行哪几项优化，在 Inline function expansion中我们可以指定对内联函数的扩展方式。Precompiled Headers类别中是关于预编译头 文件的一些选项，一般情况下都不用更改。Preprocessor类别中是关于预处理的一些选择。

4、Link 选项卡

　 　Link选项卡控制着Visual C++的连接器。在General类别中，可以指定输出的文件名，以及一些在连接过程中需要使用的额外的库文件或目 标文件，下边五个选项的含义分别为：生成调试信息；忽略所有缺省的库文件；允许递增连接方式（这种方式可以加快连接的速度）；生成MAP文件；允许进行性 能分析。在Customize中选中Use program database允许使用程序数据库。在Debug类别中，我们可以指定调试信息的类别是 Microsoft的格式，还是COFF格式，或者两种都有，选中Separate types后连接器会把调试信息分开放在PDB文件中，这样连接起来 会更快一些，但调试时速度却会慢一些。Input类别中是一些与输入库文件有关的选项，我们可以在这里指定使用或不使用某些库文件或目标文件。 Output类别中则是一些与最终输出的可执行文件有关的选项，一般情况下都不用改变。

三、Visual C++调试工具

1、调试窗口

（1）观察窗口(Watch)

　　调试程序时，可使用观察窗口监视变量和表达式。

（2）快速查看窗口(Quick watch)

　　功能和观察窗口差不多。

（3）变量窗口(Variables)

　　变量窗口有三个标签：Auto标签显示了当前语句和前一条语句用到的变量，Locals标签显示当前函数的局部变量，this标签显示了this指针执行的对象。

（4）寄存器窗口(Register)

　　可以监视CPU的寄存器、标志值以及浮点堆栈

（5）内存窗口(Memory)

　　可显示从一特定地址开始的虚拟内存。Address框允许你指定从哪个虚拟内存地址开始显示。

（6）调用栈窗口(Call stack)

　　可显示引起当前源代码语句执行的一系列函数调用，当前函数在堆栈的顶端。

（7）反汇编窗口(Disassembly)

　　可查看编译器生成的对应于源代码的汇编指令。

2、调试符号

　 　程序数据库文件(.pdb)包含了Visual C++调试器所需的调试信息和程序信息。调试信息包含了变量的名字和类型、函数原型、源代码行号、类和 结构的布局、FPO调试信息（重建堆栈帧）以及进行增量链接所需的信息。对于设置了 Program Database for Edit and Continue选项的程序，PDB还要包含执行编辑继续功能所需的信息。

3、使用断点

　　断点(BreakPoint)是运行你向调试器描述环境，并让调试器设置好程序状态的一种机制。如果没有断点，只有在程序里一步一步跟踪使用调试器。在Visual C++中，你可以设置三种类型的断点：代码定位断点、数据断点和消息断点。

四、提高调试器的查错能力

　　尽量采用编译时刻检查而不是运行时刻检查。

1、使用最高的编译警告级别/W4

　 　象if(x=2)这样的语句，默认的警告级别为/W3时不显示任何信息，但改成最高警告级别/W4时则会出现“waning C4706: assignment within conditional expression”的警告。/W4能给出一些/W3所不能给的警告。

2、在调试版本中使用/GZ编译选项

　　/GZ选项用来发现那些在发布版本里才发现的错误，包括未被初始化的自动（局部）变量、堆栈错误、不正确的函数原型等。

3、使用#pragma warning编译器指示

　　你可以使用#pragma warning编译器指示来禁止整个程序、特定的头文件、特定的代码文件或是特定的某一行代码的特定警告，这看你把#pragma放在哪里。

4、使用没有警告的编译法则/WX

　　这个编译选项把所有的警告当成错误来对待，只有在假警告被消除之后才能应用。有时编译警告可能是合理的，处理编译警告的核心是要发现错误，而不是抑制警告本身。这个法则对于大的程序开发小组来说很有帮助。最终目标是消除错误，而不是消除警告。

五、内存空间与分配

1、内存分配错误

　　动态内存分配错误有两种基本类型：内存错误和内存泄漏。

（1）内存错误

　 　当一个指针或者该指针所指向的内存单元成为无效单元，或者内存中分配的数据结构被破坏时，就会造成内存错误。指针未被初始化，指针被初始化为一个无效地 址，指针被不小心错误地修改，在与指针相关联的内存区域被释放后使用该指针（这种指针被称为虚悬(dangling)指针），这些都会使指针变为无效指 针。当通过一个错误指针或者虚悬指针对内存进行写入，或者将指针强制转换为不匹配的数据结构，又或者是写数据越界，内存自身也会遭到破坏。删除未被初始化 的指针、删除非堆指针、多次删除同一指针或者覆盖一个指针的内部数据结构，都会造成内存分配系统错误。

（2）内存泄漏

　　内存泄漏在被动态分配的内存没有被释放时产生。有许多情况会导致内存泄漏，如没有在程序的全部执行路径中释放内存，没有在析构函数中释放所有的内存等。一个程序在崩溃之前可运行的时间越长，则导致崩溃的原因与内存泄漏的关系越大。

　 　Windows会在程序结束的时候将泄漏的内存收回，因此内存泄漏是个暂时性的问题。但为什么必须消除内存泄露呢？首先，内存泄漏往往会导致系统资源的 泄漏。动态分配内存往往不仅仅代表一块存储区域，还代表了某些类型的系统资源，如文件、窗口、设备上下文、GDI对象等。其次，高质量的程序和特定的服务 器程序必须能够无限地运行下去。最后，内存泄漏往往是其他程序错误或不良编程习惯的征兆。

　　导致内参泄漏的原因：忘记释放内存；构造函数失败；存在内存泄漏的析构函数；存在内存泄漏的异常处理程序；多个返回语句；使用错误形式的delete。

2、关于内存的初始化

　　在调试版本里，堆里未被初始化的内存被0xCD字节模式填充，堆里释放的内存被0xDD字节模式填充。堆栈里被初始化的内存被0xCC字节模式填充。调试版本和发布版本里，未被初始化的全局内存都被初始化为0。

3、内存虚拟地址空间

　　Windows使用一组固定的范围来分割进程的4GB虚拟地址空间，因此有时可通过查看指针的返回值来判断指针是否有效。

（1）Windows2000虚拟地址空间划分

0~0XFFFF(64KB)：不能用来检测空指针赋值（访问冲突）

0x10000(64KB)~0x7FFEFFFF(2GB-64KB)：Win32进程私有的（非保留的），用于程序代码和数据

0x7FFF0000(2GB-64KB)~0x7FFFFFFF(2GB)：不能用来防止覆盖OS分区（访问冲突）

0x800000000(2GB)~0xFFFFFFFF(4GB)：为操作系统保留，不可访问（访问冲突）

（2）Windows2000虚拟地址空间使用

0x00030000~0x0012FFFF：线程栈

0x00130000~0x003FFFFF：堆（有时堆位于此处）

0x00400000~0x005FFFFF：可执行代码

0x00600000~0x0FFFFFFF：堆（有时堆位于此处）

0x10000000~0x5FFFFFFF：App DLLs、Msvcrt.dll、Mfc42.dll

0x77000000~0xFFFFFFFF：Advapi32.dll、Comctl32.dll、Gdi32.dll、Kernel32.dll、Ntdll.dll、Rpcrt4.dll、Shell32.dll、User32.dll

其中，0x00400000是所有版本的Windows能使用的最低基地址。

六、一些调试技术

1、调试死循环

　　使用Debug菜单下的Break命令。在Windows2000中，如果程序有输入请求，可以使用F12键中断程序，然后检查窗口的调用栈，或单步跟踪代码找到死循环的发生原因。

2、用Spy++调试与消息有关的问题

　 　调试消息的最好方案是使用Visual C++提供的Spy++工具。Spy++允许程序员查看窗口、消息、进程和线程。Spy++默认的消息输出：第 一栏显示行号。第二栏显示接受消息的句柄。第三栏中的“S”表示消息是用SendMessage发出的，“P”代表消息是由PostMessage发出 的，“R”是消息句柄的返回值。第四栏给出解码后的消息名，消息参数或返回值。

3、非常规方法

（1）重新编连你的应用程序

　　当你的程序表现出异常的或意外的行为，或者Visual C++编译器因为一个内部编译器错误而失败时，最好删除工程中的Debug或Release文件夹，从头开始重新进行编连。

（2）重新启动Visual C++

　 　Visual C++有超强的能力，但编译器的某些特性也会引起奇怪的错误。如果你的程序表现得很奇怪，你可是试着清除所有的断点，关闭或隐藏观察窗 口，检查工程设置对话框看最近做了什么修改，直至重新启动Visual C++以便消除由于Visual C++环境引起的异常行为。

（3）重新启动Windows

　　当你发现Windows或者其他程序表现出异常的或出人意料的行为时，就应该重新启动Windows，以消除操作系统给调试带来的干扰。