VC调试技术

本人资历尚浅，写这篇文章纯粹是为了起到一个抛砖引玉的作用，希望各位OIer,CSer,ACMer能够批评，指正。
程序出错的类型大致 可以分为两种，语法错误和逻辑错误。语法错误可以通过编译器的出错信息得到纠正。然而逻辑错误则不能，所以各大IDE（集成开发环境）中都提供了 debug功能，用来分析和排除程序中的逻辑错误，排除逻辑错误的过程又称调试（或debug），下面谨以VC++6.0的调试环境做介绍。
常用 的调试命令主要有：
step into 命令 快捷键：F11
单步执行每条语句，在遇到函数的时候，系统将进入函数，单步执行其中的语 句。
step over 命令 快捷键：F10
单步执行每条语句，但在遇到函数时候，系统将把函数当作“一条语句”来执行，自动执行其中 的内容，而不进入函数内部单步执行。
run to cursor 命令 快捷键：Ctrl+F10
系统将自动执行到用户光标所指的语句 前。
（这个功能很有用，可以将精力集中到有问题的地方，从而节省调试时间）
Go 命令 快捷键：F5
系统将编译，连接，自动运行 程序，但是会在程序设置了断点(breakpoint)处停下。
BuildExcute 命令 快捷键：Ctrl+F5
系统将编译，连 接，运行编译好的程序代码，因此不会在断点处停留，但是在程序执行结束之后，系统会给一个Pause，以方便用户观察输出结果。
Stop debug命令 快捷键：Shift+F5
本命令是用来终止动态调试过程的。

动态调试的主要方法——watch（监视变量）
在程序编译通过以后，当使用了step into,step over,run to cursor, go命令使系统在程序执行的过程中停下之后，系统就会进入调试状态。
调试过程中，你的程序执行窗口会调到后台，而系统窗口 中会显示你的程序，其中的黄色箭头指向的是系统下一步将要执行的语句。
而系统窗口下面的那个监视窗口就是我们将要介绍的重点.
watch 窗口被左右分成了两个部分，左面的那部分我们姑且称之为“自动监视区”（即variable窗口），而右面的我们称之为“手动监视区”。（即watch窗 口）
自动监视区是系统自动跟踪的变量名。
系统默认显示auto标签，那是显示在上一步执行过程中，程序中发生改变的变量。
locals 标签跟踪的是某一个函数中的所有变量。
上面的find sourse组合框中指示的是当前在locals标签下在跟踪的变量是属于哪一个函数的。
说 明：当find sourse组合框中的内容变成灰色时，说明系统正在运行程序，或者等待输入端的数据（通常会是这个情况），此时应当注意程序执行窗口中的内容。
然 而通常仅仅只有自动监视区所监视的变量是不够的，有时我们需要自己定义一些需要跟踪的变量——这个时候我们就要在手动监视区中输入变量名（也可以是系统认 为合法的表达式）来跟踪我们需要的值。
注意：当用户定义了一个指向数组的watch之后，在变量的左边会出现一个小的'+'号，表示这个数组可以 “展开”——显示其中每一个下标所指示的内容，这与其他高级语言的IDE有些不同。
值得一提的是VC++的一个人性化设置：在用户定义的变量很多 时，往往需要通过滚屏才能看到所有的变量——VC++在手动监视区中设定了4个标签以方便用户的使用，在这四个标签的功能是一样的！

断点的设置与一些基本的调试技巧。
断点（breakpoint）是指在调试过程中，只要运行到断点处，系统就会自动停下（除非是使 用bulidexcute命令，但那是在执行编译好的代码，在严格意义上说，这不能算是一个调试命令），通常和go命令和step over命令配合在一起使用。
设置断点的方法：在程序代码中，移动到需要设置断点的那一行上，按F9键，你可以看到代码行的左端出现了一个红色的 圆点——那是VC++中断点的标志，以后程序在调试过程中，每次执行到这里，都会停下，方便用户观察watch中的内容。
去除断点的命令与设置断 点的命令相同：在已设置断点的地方，再按一次F9键，左端的红色圆点就消失，断点被去除了。
有的时候，我们并不是不需要断点，而是“暂时”不需要 它，这时可以在已设置断点的地方，按Ctrl+F9键，你可以看到原本实心的圆点变成了一个空心的圆圈——断点暂时失效了。恢复断点功能也是按 Ctrl+F9。这个功能在程序很长，需要很多断点的时候尤其有用。
条件断点技术——其实就是在一些分支语句内部设置断点，这个技术很实用，尤其 在程序的某个分支部分发生问题的时候。
关于断点设置在哪里。这可以说是因人而异，而且是一个相当有艺术性的内容，我不想多说什么，但是有一个基本 的原则就是，不要连续设置断点，所谓断点，也可以说是“段”点，在需要连续观察的地方，应当使用step over或者step into命令。

好了，调试命令基本上就是这些，下面我想谈谈我个人在调试过程中的一些心得和体会：
1.动态调 试不是万能的。虽然动态调试能解决几乎所有的非算法性的问题，但是动态调试要消耗大量的时间这点也是无庸质疑的——而且会扰乱编程者的思路。其实相当多的 错误往往只是因为键盘按错（“手误”）导致的。这种错误在动态调试中很难发现，所以对于每一个程序，在要开始进行调试前，都应当再整理一遍思路，仔细地通 读一遍程序，用所谓的“静态查错”的方法先将一些显而易见的低级错误先解决掉，同时也可以确定调试的重点。这样做可以大大缩短调试时间，同时能使自己更容 易发现一些思路方面的错误。
2.调试时思路要跟着程序转。说白了就是要集中精力于正在调试的语句段和正在变化的变量上。
3.模块化能有效 缩短调试时间。其实模块化不仅仅能有效的缩短开发时间，更能有效的缩短调试时间。首先，模块化使得我们够方便的使用step over命令，而减少断点的设置。其次，程序出错的地方往往就是在几个关键点上，使用了模块化设计思路以后，我们就可以集中精力在那些关键点上，省去了不 必要的单步调试。当然，能面向对象就更好了。
4.多用断点和run to cursor命令，减少单步调试的使用——那样太费时间了。
5. 调试不要破坏程序的原本结构。许多人喜欢在调试过程中输出一些中间变量的值，认为这样做比较直观——当然，这也是一个很重要的手段，尤其在反复递归和循环 嵌套的时候。不过我不推荐在非递归的程序中使用这种方法。这种方法最大的问题就是破坏了程序原本的结构和逻辑，除非你在原本程序设计时就想到这一点。这点 在程序很长或者思路很复杂时尤为明显。否则为什么所有的编译模式的程序语言都不约而同的提供了watch这一手段？解释模式的程序语言？那是没有办法……
6. 遇到bug时不要急于修改程序。也就是不要乱打补丁。道理和第5条一样，要先仔细分析，然后在决定是否要修改——总之，要冷静。尤其是删除程序段的时候， 我建议先把认为不需要的程序段先注释掉。等到调试成功后再删不迟。
7.关于测试数据。唉……这又是另外一个问题了，我这方面的经验实在是太少了 ——以后再写了！