调试利器-----------------------DebugTrace for Windows简介
调试利器-----------------------DebugTrace for Windows简介
调试利器-----------------------DebugTrace for Windows简介 首先申明一下，贴这个贴子的目的之一是王婆卖瓜似的推销子做的东东；梁歪一个目的呢就是希望和大家交流一下调试的技巧。:P 软件请到这里下载http://go6.163.com/spring22/html/debugtrace.htm 具体的说明在zip包内。为了能够跟踪用户需求，以及bug反映，请下载的用户发一个mail到luon@hotmail.com 实在不行的话，在这下面签个到留下你的mail地址，谢谢
作为一名C/C++程序员，你最大的苦恼是什么？如何处理Debug版和release版本之间的差异？如何在realese版本里面进行调试？如何更好地调试实时程序，如何更好地调试多线城程序，如何调试GDI程序……
我想作为一个有经验的程序员，对付这样的问题，应该都有自己的一套方法。但是能不能够把这些方法共享给大家，提供一个能够普及的东东呢？本人一直很迷惑。现在有了，答案就是DebugTrace。
作为一名C/C++程序员，我最大的苦恼就是数组越界访问的问题，你的呢？
很多时候，对某个程序的调试，不是我们平时的F9[设置断点],F5[运行],F10[单步执行],F11[跳入]可以解决的。这个问题比较突出的比如GDI程序的调试，键盘程序的调试。当你按下键盘的时候，会触发键盘消息，但你移动鼠标进行操作的后，会导致出现无效区域，从而触发WM_PAINT的调用。如果被调试对象此时正好就对这些消息感兴趣的话，问题就出现了。在这种情况下，会对你的调试带来一定的影响。怎门半才好呢？常见的调试GDI的方法是双显示器或者，远程调试。键盘调试的话，用其它的输入方式来调试。这样就出现了很多针对性很强的个别方法，我们能不能够有其他通用一点的方法呢？对了！有人想到了，我们可以写LOG&TRACE文件。这肯定是一个绝好的方法，有了这样的方法，才使很多的程序员在debug的苦海里看到了一点微茫的希望。
但是是不是有了这样的方法就一劳永逸了呢？其实问题远远不是如此。才仅仅是个开头。
比如，想写一些信息到LOG文件里面去，可能会有如下的代码:
char ，”[%d]The First Log Information”,1);
这段代码基本上正确，初看的时候还很顺眼，但是有经验的程序员却可以一样看出其中的问题。你看出来了吗？问题在哪里？问题出在了字符数组szBuffer的长度上，发生了数组的越界访问，这样的一段程序放在程序里，无一是一颗炸弹，随时会跳出来兴风作浪。程序改进的方法就是加大数组的长度。但是在实际的情况下，究竟缓冲区需要设置成多大呢？这个很难把握的，唯一的回答就是具体情况具体分析了。如果有一个程序里面有很多的地方需要写LOG呢?不会是满篇都出现这样的语句吧？这样的代码，不仅运行效率不高，开发效率也不会高，还影响程序的可读性。有人说，将buffer设置成全局的，不错的主意，可是这个缓冲区究竟要设多大呢？这确实是个问题，聪明的办法是此路不通另辟坦途。
其实可能很多人都想到了，我们完全可以用C++的string来解决这个问题。当然这个问题是解决了，但是如果你想在debug版本和release版本之间稍有不通时怎么办呢？通常的办法是适用预编译指令，比如:
#
，”[%d]The First Log Information”,1);
#大量的这样的语句出现在程序中，不仅需要专门的编译器的与编译指令方面的知识，还会影响程序的可读性，而且如果一不小心与编译指令本身除了点问题的话，错误提示不能正确指示的。这反倒增加了麻烦。
解决之道呢？强烈推荐使用DebugTrace，J
有了写LOG文件之后，是不是就万事大吉了呢？回答当然是否定的。请考虑多线程时候的情况。在多线程的情况下，会出现什么样的问题呢？首先是我们在往disk或者memeory写文件的时候会出现问题，试想如果有很多线程再同时往同一个地方写，不会发生访问冲突吗？幸运的是在windows系列的大部分OS里面，文件I/O已经是异步访问模式了。这个不是问题，可是既然buffer是全局的，如何保证buffer的访问不发生冲突呢？这是必要用到线城间通讯与同步的技术，一个小小的写LOG操作需要这么复杂的东东来完成它，不做也罢~！
还有问题，写LOG的话，需要等待程序运行完毕了，才来验证写LOG的结果，这样的操作实时性差，在有的系统里面，需要实时地知道当前程序运行到什么地方了。写LOG有延时性的问题，怎么办呢？
用过java的朋友都知道，在java里面可以有一个很cool的东东java虚拟机JVM,任何需要跟踪调试的信息都可以print到JVM上赖进行检查，这对调试程序的程序员来讲是在事太方便了。想不想再你的C/C++程序的调试过程中也有这样的东东呢？
想的话，不妨一试DebugTrace！
在windows系统里面系统维护着一个虚拟的窗口叫做DebugWindow.使用过DBGWND，softice或者VC或其他开发工具自带的调试工具都用到了这些东东。习惯使用这些东东的程序员如何将自己写的信息写到里面去，在调试的时候实时检查呢？答案就在DebugTrace。
同时很多人也关心，如何将我的LOG信息写到系统的事件记录器里面去呢？这也是DebugTrace的一个功能哦。
对于程序员来讲，调试的目的是要找出程序里面的bug。Bug的表现方式当然是在那个文件的那一行。如何将这些也表现到你的明明白白地告诉你呢？对于多线程的程序，如何知道那条信息，是那个线程写出来的呢？尤其是多个线程同时使用同一个线程函数的时候呢？如果堆时间要求较高的话，如何作出细微的分析呢？……
答案就在DebugTrace。
目前的DebugTrace已经经过了好多实际项目的考验。表现一直不错。尤其在某个多线程SOCKET和另外一个COM的项目里面表现一直不错。
有句话叫做“国之利器，不可示人”，但是我觉得有了交流才会有提高。所以但愿DebugTrace对你有所帮助。值得一试的。
