debug和release的区别
2016-01-13 13:44
309 查看
最近工作的项目在测试时以debug版本测试没这问题,结果上线发布时用的release版,从市场下载下来就出现了一个严重问题,最后开发查找原因说是debug模式部分地方没有像release版那样完全释放内存,我理解的意思是release释放了,debug表面释放但是实际并没有释放,所以造成我们release版出现问题而debug没有该问题。
以下是从网上摘取的Debug和Release的区别:
Debug和Release仅仅是编译选项的不同,那么为什么要区分Debug和Release版本呢?
Debug和Release,主要是针对其面向的目标不同的而进行区分的。
Debug通常称为调试版本,通过一系列编译选项的配合,编译的结果通常包含调试信息,而且不做任何优化,以为开发人员提供强大的应用程序调试能力。
而Release通常称为发布版本,是为用户使用的,一般客户不允许在发布版本上进行调试。所以不保存调试信息,同时,它往往进行了各种优化,以期达到代码最小和速度最优。为用户的使用提供便利。
下面仅就默认的Debug和Release版本的选项进行比较,详细的编译选项可以看MSDN的说明。
我们将默认的Debug和Release的选项设置进行比较,过滤掉相同设置,主要的不同如下:
编译选项:/Od /D "_DEBUG" /Gm /RTC1 /MDd /Fo"Debug\\" /ZI
链接选项:/OUT:"D:\MyProject\logging\Debug\OptionTest.dll" /INCREMENTAL
默认的Release设置如下:
编译选项:/O2 /GL /D "NDEBUG" /FD /MD /Fo"Release\\" /Zi
链接选项:/OUT:"D:\MyProject\logging\Release\OptionTest.dll" /INCREMENTAL:NO
MDd与MD
首先,Debug版本使用调试版本的运行时库(/MDd选项),Relase版本则使用的是发布版本的运行时库(vcrt.dll)。其区别主要在于运行时的性能影响。调试版本的运行时库包含了调试信息,并采用了一些保护机制以帮助发现错误,也因此,其性能不如发布版本。编译器提供的Runtime Library很稳定,不会造成Release版本错误,倒是由于Debug版本的Runtime Library加强了对错误的检测,如堆内存分配检查等,反而会报告错误,应当指出,如果Debug有错误,而Release版本正常,程序肯定是有Bug的,只是我们还没有发现。
ZI与Zi
其次,/ZI选项与/Zi选项。通过使用/ZI选项,可以在调试过程修改代码而不需要重新编译。这是个调试的好帮手,可如果我们使用Release版本,这将变得不可行。
Od与O2
/O2与/Od选项:Od是关闭编译器优化,普遍用于Debug版本。而O2选项是创建最快速代码,这当然是Release版本的不二选择。
RTCx选项
/RTCx选项,这个选项比较强,它可以让编译器插入动态检测代码以帮助你检测程序中的错误。比如,它会将局部变量初始化为非零值。包括用0xCC初始化所有自动变量,0xCD初始化堆中分配的内存(即new的内存),使用0xDD填充被释放的内存(即delete的内存),0xFD初始化受保护的内存(debug版在动态分配内存的前后加入保护内存以防止越界访问)。这样做的好处是这些值都很大,一般不可能作为指针,作为数值也很少用到,而且这些值很容易辩认,因此有利于在Debug版本中发现Release版才会遇到的错误。
另外,通过函数指针调用函数时,会通过检查栈指针验证函数调用的匹配性(防止原型不匹配)。
使用/RTCx选项会造成Debug版本出错,而Release版本正常的现象,因为Release版中未初始化的变量是随机的,很可能使指针指向了有效但是错误的地址,从而掩盖了错误。
说了这么多好处,这个编译选项有个限制:那就是只能在/Od选项下使用。
Gm,INCREMENTAL or NO
编译选项中的Gm和链接选项中的INCREMENTAL都只为一个目的,加快编译速度。我们经常遇上这样的问题,只修改了一个头文件,结果却造成所有动态库的重新编译。而这两个选项就是为了解决这样的问题。
如果启用了/Gm开关,编译器在项目中的.idb文件中存储了源文件和类定义之间的依赖关系。之后的编译过程中使用.idb文件中的信息确定是否需要编译某个源文件,哪怕是此源文件已经包含了已修改的.h文件。
INCREMENTAL开关默认是开启的。使用增量链接生成的可执行文件或者动态链接库会大于非增量链接的程序,因为有代码和数据的填充。另外,增量链接的文件还包含跳转trunk以处理函数重定位到新地址。
MSDN上明确指出:为确保最终发布版本不包含填充或者trunk,请非增量链接程序。
_DEBUG与NDEBUG
这个话题放在本节的最后,却是最重要的一个选项。这两个是编译器的预处理器定义,默认情况下_DEBUG用于Debug版本,而NDEBUG用于Release版本。它们可以说是重要的无以复加。因为,assert系列的断言仅仅在_DEBUG下生效!
下面是assert.h文件中摘出来的:
#ifdef NDEBUG
#define assert(_Expression) ((void)0)
#else
#ifdef __cplusplus
extern "C" {
#endif
_CRTIMP void __cdecl _wassert(__in_z const wchar_t * _Message, __in_z const wchar_t *_File, __in unsigned _Line);
#ifdef __cplusplus
}
#endif
#define assert(_Expression) (void)( (!!(_Expression)) || (_wassert(_CRT_WIDE(#_Expression), _CRT_WIDE(__FILE__), __LINE__), 0) )
#endif /* NDEBUG */
可以看出在未定义_DEBUG时,assert变成一条空语句不被执行。
也就是说,我们现在所有发布的版本无法使用断言机制进行程序调试。
以下是从网上摘取的Debug和Release的区别:
Debug和Release仅仅是编译选项的不同,那么为什么要区分Debug和Release版本呢?
Debug和Release,主要是针对其面向的目标不同的而进行区分的。
Debug通常称为调试版本,通过一系列编译选项的配合,编译的结果通常包含调试信息,而且不做任何优化,以为开发人员提供强大的应用程序调试能力。
而Release通常称为发布版本,是为用户使用的,一般客户不允许在发布版本上进行调试。所以不保存调试信息,同时,它往往进行了各种优化,以期达到代码最小和速度最优。为用户的使用提供便利。
下面仅就默认的Debug和Release版本的选项进行比较,详细的编译选项可以看MSDN的说明。
我们将默认的Debug和Release的选项设置进行比较,过滤掉相同设置,主要的不同如下:
编译选项:/Od /D "_DEBUG" /Gm /RTC1 /MDd /Fo"Debug\\" /ZI
链接选项:/OUT:"D:\MyProject\logging\Debug\OptionTest.dll" /INCREMENTAL
默认的Release设置如下:
编译选项:/O2 /GL /D "NDEBUG" /FD /MD /Fo"Release\\" /Zi
链接选项:/OUT:"D:\MyProject\logging\Release\OptionTest.dll" /INCREMENTAL:NO
MDd与MD
首先,Debug版本使用调试版本的运行时库(/MDd选项),Relase版本则使用的是发布版本的运行时库(vcrt.dll)。其区别主要在于运行时的性能影响。调试版本的运行时库包含了调试信息,并采用了一些保护机制以帮助发现错误,也因此,其性能不如发布版本。编译器提供的Runtime Library很稳定,不会造成Release版本错误,倒是由于Debug版本的Runtime Library加强了对错误的检测,如堆内存分配检查等,反而会报告错误,应当指出,如果Debug有错误,而Release版本正常,程序肯定是有Bug的,只是我们还没有发现。
ZI与Zi
其次,/ZI选项与/Zi选项。通过使用/ZI选项,可以在调试过程修改代码而不需要重新编译。这是个调试的好帮手,可如果我们使用Release版本,这将变得不可行。
Od与O2
/O2与/Od选项:Od是关闭编译器优化,普遍用于Debug版本。而O2选项是创建最快速代码,这当然是Release版本的不二选择。
RTCx选项
/RTCx选项,这个选项比较强,它可以让编译器插入动态检测代码以帮助你检测程序中的错误。比如,它会将局部变量初始化为非零值。包括用0xCC初始化所有自动变量,0xCD初始化堆中分配的内存(即new的内存),使用0xDD填充被释放的内存(即delete的内存),0xFD初始化受保护的内存(debug版在动态分配内存的前后加入保护内存以防止越界访问)。这样做的好处是这些值都很大,一般不可能作为指针,作为数值也很少用到,而且这些值很容易辩认,因此有利于在Debug版本中发现Release版才会遇到的错误。
另外,通过函数指针调用函数时,会通过检查栈指针验证函数调用的匹配性(防止原型不匹配)。
使用/RTCx选项会造成Debug版本出错,而Release版本正常的现象,因为Release版中未初始化的变量是随机的,很可能使指针指向了有效但是错误的地址,从而掩盖了错误。
说了这么多好处,这个编译选项有个限制:那就是只能在/Od选项下使用。
Gm,INCREMENTAL or NO
编译选项中的Gm和链接选项中的INCREMENTAL都只为一个目的,加快编译速度。我们经常遇上这样的问题,只修改了一个头文件,结果却造成所有动态库的重新编译。而这两个选项就是为了解决这样的问题。
如果启用了/Gm开关,编译器在项目中的.idb文件中存储了源文件和类定义之间的依赖关系。之后的编译过程中使用.idb文件中的信息确定是否需要编译某个源文件,哪怕是此源文件已经包含了已修改的.h文件。
INCREMENTAL开关默认是开启的。使用增量链接生成的可执行文件或者动态链接库会大于非增量链接的程序,因为有代码和数据的填充。另外,增量链接的文件还包含跳转trunk以处理函数重定位到新地址。
MSDN上明确指出:为确保最终发布版本不包含填充或者trunk,请非增量链接程序。
_DEBUG与NDEBUG
这个话题放在本节的最后,却是最重要的一个选项。这两个是编译器的预处理器定义,默认情况下_DEBUG用于Debug版本,而NDEBUG用于Release版本。它们可以说是重要的无以复加。因为,assert系列的断言仅仅在_DEBUG下生效!
下面是assert.h文件中摘出来的:
#ifdef NDEBUG
#define assert(_Expression) ((void)0)
#else
#ifdef __cplusplus
extern "C" {
#endif
_CRTIMP void __cdecl _wassert(__in_z const wchar_t * _Message, __in_z const wchar_t *_File, __in unsigned _Line);
#ifdef __cplusplus
}
#endif
#define assert(_Expression) (void)( (!!(_Expression)) || (_wassert(_CRT_WIDE(#_Expression), _CRT_WIDE(__FILE__), __LINE__), 0) )
#endif /* NDEBUG */
可以看出在未定义_DEBUG时,assert变成一条空语句不被执行。
也就是说,我们现在所有发布的版本无法使用断言机制进行程序调试。
相关文章推荐
- Andorid5.0原生下拉刷新简单使用
- spring 定时任务执行两次 解决方案
- unix设计原则
- LeetCode - Flatten Binary Tree to Linked List
- C# 根据Word模版生成Word文件
- 学习 JavaScript 最难点之一 -- 理解prototype(原型)
- 快速排序
- Android退出应用最优雅的方式(改进版)
- C语言版本历史
- 深入分析JavaWeb Item51 -- Spring依赖注入
- Linux---密码重置与防范
- [Android] Android开发优化之——对Bitmap的内存优化
- php基础
- git分布式版本管理,配置流程,自己研究,win10
- Error:Execution failed for task ':app:clean'. > Unable to delete file: xxx.file
- 【杭电oj】5499 - SDOI(结构体排序,水)
- 第0条:拘泥于小节
- android 简单试题系统
- Hadoop科普文—常见的45个问题解答
- hdu 2055 An easy problem (java)