《C语言程序设计进阶教程》一3.3 后执行式和交互式调试

本文讲的是<b>C语言程序设计进阶教程一3.3　后执行式和交互式调试</b>,要调试一个程序是需要策略的。你需要把程序分为几阶段，在每一阶段的基础上隔离问题。在把不同部分整合起来之前确保程序在每一阶段都是正确的。例如，把一个程序看作3个阶段：①从一个文件中读取一些整数；②把整数排序；③把排好序的整数存到另一个文件中。在整合之前测试每一部分叫作单元测试。对于单元测试，你经常需要写一些额外的代码作为单独部分的“驱动”。例如，要在还未从文件中获得数据的情况下测试排序是否正常工作了，你就需要编写能够产生数据的代码（也许使用一个随机数生成器）。调试可能是交互式或者是后执行式的。如果一个程序会花费几个小时，你就不会想要用交互式来调试这个程序了。相反，你会想要程序打印出调试信息（叫作日志）。这个信息帮助你知道在长时间的执行期间发生了什么。另一种情况是调试一个与其他程序有着即时通信要求的程序。例如，你调试一个程序，此程序与另一个程序通过网络进行通信。如果你对这个程序进行交互式的调试就会让它慢很多，其他程序会认为网络中断从而停止与你的程序进行通信。另一种情形是你的程序与实体世界进行关联（例如控制一个机器人）。实体世界不会等待你的程序，它也不会慢下来。打印日志也会让程序慢下来，因此不要添加过多的日志。

在许多其他情况下，你可以让你的程序慢下来，对程序进行交互式的调试——运行程序的一些部分，观察中间的结果，修改程序，再次运行它们，继续这个过程直至你认为程序正确。对于交互式调试，打印调试信息通常是低效费时的。对交互式调试而言打印调试信息存在多个问题：

需要插入代码来打印调试信息。这将会耗费相当的精力。多数情况下，调试信息必须在随后被移除，因为此信息不应该出现在最终的代码和它的输出中。

如果只有很少的信息，那么就会缺少足够的信息帮助你判断是哪里错了。

如果有太多的信息，一些信息可能会是不相关的，应该被忽略。要得到恰好数量的信息，不多也不少，是很困难的。

最糟糕的是，问题可能会出现在意想不到的地方，而那里却并未插入调试信息。结果就是需要添加越来越多的调试信息进来。这将会是耗时耗力的。

与在交互式调试中使用调试信息相比，gdb（或DDD）在多数情况下是一个更好的工具。前文已经展示过一些gdb指令了。在本书后续部分会介绍更多指令。

原文标题：C语言程序设计进阶教程一3.3　后执行式和交互式调试