dedecms织梦内容管理系统    
首页 | java | C/C++ | PHP | 操作系统 | ajax | 脚本编程 | 安全技术 | 本站下载页 | flex | CRM | 专题 | QQ群 | 测试中心 | 会员中心 | 积分规则
  当前位置:主页>C/C++>C/C++技术资料>文章内容
调试Release版本应用程序
来源:不详     作者:    

引言
如果在您的开发过程中遇到了常见的错误,或许您的Release版本不能正常运行而Debug版本运行无误,那么我推荐您阅读本文:因为并非如您想象的那样,Release版本可以保证您的应用程序可以象Debug版本一样运行。

如果您在开发阶段完成之后或者在开发进行一段时间之内从来没有进行过Release版本测试,然而当您测试的时候却发现问题,那么请看我们的调试规则1:

规则1: 经常性对开发软件进行Debug和Release版本的常规测试.

测试Release版本的时间间隔越长,排除问题的难度越大,至少对Release版本进行每周1次的测试,可以使您在紧凑的开发周期内节省潜在的排故时间.

不要随意删除Release版本需要的代码
这点看起来似乎再明显不过,但却是开发人员无意中经常犯的错误,原因在于编译器编译Release版本时候会主动排除在代码中存在的宏,例如ASSERT和TRACE在Release版本会自动排除,这样导致的问题是您在这些宏当中运行的代码也被随之删除,这是非常危险的事情J,例如:

   ASSERT(m_ImageList.Create(MAKEINTRESOURCE(IDB_IMAGES), 16, 1, RGB(255,255,255)));

这样的代码在Debug模式不会出错,图像列表也自动创建了,然而在Release版本呢?后继使用m_ImageList对象只会造成程序的Crash!,因此ASSERT宏中尽量使用逻辑运算符作为验证。

规则 2: 不要将代码放置在仅在某种编译选项中执行的地方,对于使用_DEBUG等编译选项宏内部的代码必须不影响整个程序的使用.

规则 3: 不要使用规则2作为评判标准来删除ASSERT宏,ASSERT宏是个有用的工具,但容易使用错误.

使Debug编译模式接近Release模式
如果您的Release版本存在的问题是由代码被编译器自动排除造成的,那么通过这个方法您的问题可能会重现.

一些问题的产生可能是由于不同编译选项之间预定义符号造成的,因此您可以更改编译模式下的预定义符号,从而使您的Debug模式接近Release模式,观察错误是否产生,更改编译预定义符号方法如下:

Alt-F7打开项目设置,在/C 页面,选择"General"类别,更改"_DEBUG"符号为"NDEBUG".
在/C 页面, 选择"Preprocessor"类别,添加预定义符号"_DEBUG"到"Undefined Symbols"栏.
使用"Rebuild All"重新编译
如果通过上面设置,您在Release编译模式下面的问题在Debug模式下重现,那么请您依据以下步骤对您的代码进行修改:

查找ASSERT排除其中的所有重要执行语句,或者将ASSERT修改为VERIFY.
检查"#ifdef _DEBUG" 内所有代码,排除Release模式使用的代码.
查找TRACE 排除其中的所有重要执行语句. TRACE和ASSERT一样,仅在Debug模式下编译.
如果通过上面修改更正了您在Debug模式下的问题,那么您可以重新编译Release模式,非常有可能您可以解决先前存在的问题!.

错误的假定造成编译模式错误
您是否经常性的假定您的变量或者对象被初试化成某个指定的值(可能0)?您是否假定你所有关联到的资源在应用程序中都存在?这些也是Debug和Release模式下不同问题产生的原因.

规则 4: 除非您在代码中对变量进行初始化,否则不能作出如上假定. 包括全局变量,自动变量,申请对象和new对象.

这种情况还常常发生在内存顺序的问题,记得原来使用结构体的时候为了使用方便,比较两个结构体对象使用memcmp,在Debug版本工作正常,而Release版本计算出错误的解,看来的确不能进行错误的假定!

规则 5: 确保删除资源的所有引用都被删除,例如resource.h中的定义.

软件开发中,不同编译版本对变量和内存的初始化是不同的. 如果您假定变量初始化为0,那么在Win9x系统的Release模式下,会出现异常现象。因此对所有变量,内存显式清0是较为安全的做法.

如果您引用了已经被删除的资源,您的Debug版本可以正常工作,但是Release版本可能会crash.

您是否相信编译器?
编译器警告级别和编译噪音有着相当大的关系.

通过提高编译器警告级别可增加程序隐藏问题暴露的机会.通常设置警告级别在"Level 3"或者 "Level 4".编译并解决所有警告,这是发布Release版本应用程序的一个很好的建议.这能暴露会使您的应用程序出现问题的很多初始化问题和其它潜在的错误.

规则 6: 开始项目之前先将编译警告级别设置在"Level 3" 或者 "Level 4" ,登记代码之前确保消灭所有警告!.

总结报告
编译模式下的调试
曾经不止一次的听到一些VC开发者说Release模式下面不能进行调试,幸运的是:通过相应设置,可以在Release模式进行调试,因此那只不过是一个以讹传讹的荒谬说法而已.

[1]  

 

 

上一篇:Visual C++ 6.0的文档/视结构   下一篇:形形色色的自定义消息(上)
[收藏] [推荐] [评论(0条)] [返回顶部] [打印本页] [关闭窗口]  
用户名: 新注册) 密码: 匿名评论
评论内容:(不能超过250字,需审核后才会公布,请自觉遵守互联网相关政策法规。
 §最新评论
  热点文章
·C语言数组排序小结
·Python 与 C++ 程序的简单实例对
·c++ 数组与指针
·C++中的内存管理(new、delete、
·如何用C语言开发DSP嵌入式系统
·如何用C语言开发DSP嵌入式系统
·Linux下C语言编程
·学习arm的话先看哪本书?
·C++初学者应该关心的优秀图书一
·利用C语言小程序来解决大问题
·用C语言写PHP扩展的步骤
·用C语言扩展PHP功能
  相关文章
·Visual C++ 6.0的文档/视结构
·形形色色的自定义消息(上)
·轻轻松松C to C++ (一)
·形形色色的自定义消息(下)
·文档 视图 框架窗口间的关系和消
·哈夫曼编/译码演示系统的C程序
·使用strcpy的几点心得
·如何在C/C++中调用Java
·MFC的子类化技术
·在可管理C++中封装值类型
·面向对象的关系数据库设计
·位图基础知识及如何在客户区中显
  相关信息
copy right @ 百家拳软件项目研究室 2007 辽ICP备07011763