皮皮网
皮皮网

【rootexplorer 源码】【仿嘀咕网源码】【个人资源源码】release源码解析

来源:微信裂变分销系统源码 发表时间:2024-11-30 12:29:25

1.Debug版本和Release版本有什么区别?
2.VC DEBUG和 release区别
3.release和debugrelease和debug的码解区别
4.Debug和Release的区别
5.Java并发必会,深入剖析Semaphore源码
6.ionic debug 和release 的区别

release源码解析

Debug版本和Release版本有什么区别?

       一、码解Debug 和 Release 编译方式的码解本质区别

        Debug 通常称为调试版本,它包含调试信息,码解并且不作任何优化,码解便于程序员调试程序。码解rootexplorer 源码Release 称为发布版本,码解它往往是码解进行了各种优化,使得程序在代码大小和运行速度上都是码解最优的,以便用户很好地使用。码解

        Debug 和 Release 的码解真正秘密,在于一组编译选项。码解下面列出了分别针对二者的码解选项(当然除此之外还有其他一些,如/Fd /Fo,码解但区别并不重要,码解通常他们也不会引起 Release 版错误,在此不讨论)

        Debug 版本:

        /MDd /MLd 或 /MTd 使用 Debug runtime library(调试版本的运行时刻函数库)

        /Od 关闭优化开关

        /D "_DEBUG" 相当于 #define _DEBUG,打开编译调试代码开关(主要针对

        assert函数)

        /ZI 创建 Edit and continue(编辑继续)数据库,这样在调试过

        程中如果修改了源代码不需重新编译

        /GZ 可以帮助捕获内存错误

        /Gm 打开最小化重链接开关,减少链接时间

        Release 版本:

        /MD /ML 或 /MT 使用发布版本的运行时刻函数库

        /O1 或 /O2 优化开关,使程序最小或最快

        /D "NDEBUG" 关闭条件编译调试代码开关(即不编译assert函数)

        /GF 合并重复的字符串,并将字符串常量放到只读内存,防止

        被修改

        实际上,Debug 和 Release 并没有本质的界限,他们只是一组编译选项的集合,编译器只是按照预定的选项行动。事实上,我们甚至可以修改这些选项,从而得到优化过的调试版本或是带跟踪语句的发布版本。

        二、哪些情况下 Release 版会出错

        有了上面的介绍,我们再来逐个对照这些选项看看 Release 版错误是怎样产生的

        1. Runtime Library:链接哪种运行时刻函数库通常只对程序的性能产生影响。调试版本的 Runtime Library 包含了调试信息,并采用了一些保护机制以帮助发现错误,因此性能不如发布版本。编译器提供的 Runtime Library 通常很稳定,不会造成 Release 版错误;倒是由于 Debug 的 Runtime Library 加强了对错误的检测,如堆内存分配,有时会出现 Debug 有错但 Release 正常的现象。应当指出的是,如果 Debug 有错,即使 Release 正常,程序肯定是有 Bug 的,只不过可能是 Release 版的某次运行没有表现出来而已。

        2. 优化:这是仿嘀咕网源码造成错误的主要原因,因为关闭优化时源程序基本上是直接翻译的,而打开优化后编译器会作出一系列假设。这类错误主要有以下几种:

        (1) 帧指针(Frame Pointer)省略(简称 FPO ):在函数调用过程中,所有调用信息(返回地址、参数)以及自动变量都是放在栈中的。若函数的声明与实现不同(参数、返回值、调用方式),就会产生错误————但 Debug 方式下,栈的访问通过 EBP 寄存器保存的地址实现,如果没有发生数组越界之类的错误(或是越界“不多”),函数通常能正常执行;Release 方式下,优化会省略 EBP 栈基址指针,这样通过一个全局指针访问栈就会造成返回地址错误是程序崩溃。C++ 的强类型特性能检查出大多数这样的错误,但如果用了强制类型转换,就不行了。你可以在 Release 版本中强制加入 /Oy- 编译选项来关掉帧指针省略,以确定是否此类错误。此类错误通常有:

        ● MFC 消息响应函数书写错误。正确的应为

        afx_msg LRESULT OnMessageOwn(WPARAM wparam, LPARAM lparam);

        ON_MESSAGE 宏包含强制类型转换。防止这种错误的方法之一是重定义 ON_MESSAGE 宏,把下列代码加到 stdafx.h 中(在#include "afxwin.h"之后),函数原形错误时编译会报错

        #undef ON_MESSAGE

        #define ON_MESSAGE(message, memberFxn) { message, 0, 0, 0, AfxSig_lwl, (AFX_PMSG)(AFX_PMSGW)(static_cast< LRESULT (AFX_MSG_CALL CWnd::*)(WPARAM, LPARAM) > (&memberFxn) },

        (2) volatile 型变量:volatile 告诉编译器该变量可能被程序之外的未知方式修改(如系统、其他进程和线程)。优化程序为了使程序性能提高,常把一些变量放在寄存器中(类似于 register 关键字),而其他进程只能对该变量所在的内存进行修改,而寄存器中的值没变。如果你的程序是多线程的,或者你发现某个变量的值与预期的不符而你确信已正确的设置了,则很可能遇到这样的问题。这种错误有时会表现为程序在最快优化出错而最小优化正常。把你认为可疑的变量加上 volatile 试试。

        (3) 变量优化:优化程序会根据变量的使用情况优化变量。例如,函数中有一个未被使用的变量,在 Debug 版中它有可能掩盖一个数组越界,而在 Release 版中,这个变量很可能被优化调,此时数组越界会破坏栈中有用的数据。当然,实际的情况会比这复杂得多。与此有关的个人资源源码错误有:

        ● 非法访问,包括数组越界、指针错误等。例如

        void fn(void)

        {

        int i;

        i = 1;

        int a[4];

        {

        int j;

        j = 1;

        }

        a[-1] = 1;//当然错误不会这么明显,例如下标是变量

        a[4] = 1;

        }

        j 虽然在数组越界时已出了作用域,但其空间并未收回,因而 i 和 j 就会掩盖越界。而 Release 版由于 i、j 并未其很大作用可能会被优化掉,从而使栈被破坏。

        3. _DEBUG 与 NDEBUG :当定义了 _DEBUG 时,assert() 函数会被编译,而 NDEBUG 时不被编译。除此之外,VC++中还有一系列断言宏。这包括:

        ANSI C 断言 void assert(int expression );

        C Runtime Lib 断言 _ASSERT( booleanExpression );

        _ASSERTE( booleanExpression );

        MFC 断言 ASSERT( booleanExpression );

        VERIFY( booleanExpression );

        ASSERT_VALID( pObject );

        ASSERT_KINDOF( classname, pobject );

        ATL 断言 ATLASSERT( booleanExpression );

        此外,TRACE() 宏的编译也受 _DEBUG 控制。

        所有这些断言都只在 Debug版中才被编译,而在 Release 版中被忽略。唯一的例外是 VERIFY() 。事实上,这些宏都是调用了 assert() 函数,只不过附加了一些与库有关的调试代码。如果你在这些宏中加入了任何程序代码,而不只是布尔表达式(例如赋值、能改变变量值的函数调用 等),那么 Release 版都不会执行这些操作,从而造成错误。初学者很容易犯这类错误,查找的方法也很简单,因为这些宏都已在上面列出,只要利用 VC++ 的 Find in Files 功能在工程所有文件中找到用这些宏的地方再一一检查即可。另外,有些高手可能还会加入 #ifdef _DEBUG 之类的条件编译,也要注意一下。

        顺便值得一提的是 VERIFY() 宏,这个宏允许你将程序代码放在布尔表达式里。这个宏通常用来检查 Windows API 的返回值。有些人可能为这个原因而滥用 VERIFY() ,事实上这是危险的,因为 VERIFY() 违反了断言的思想,不能使程序代码和调试代码完全分离,最终可能会带来很多麻烦。因此,php app后台源码专家们建议尽量少用这个宏。

        4. /GZ 选项:这个选项会做以下这些事

        (1) 初始化内存和变量。包括用 0xCC 初始化所有自动变量,0xCD ( Cleared Data ) 初始化堆中分配的内存(即动态分配的内存,例如 new ),0xDD ( Dead Data ) 填充已被释放的堆内存(例如 delete ),0xFD( deFencde Data ) 初始化受保护的内存(debug 版在动态分配内存的前后加入保护内存以防止越界访问),其中括号中的词是微软建议的助记词。这样做的好处是这些值都很大,作为指针是不可能的(而且 位系统中指针很少是奇数值,在有些系统中奇数的指针会产生运行时错误),作为数值也很少遇到,而且这些值也很容易辨认,因此这很有利于在 Debug 版中发现 Release 版才会遇到的错误。要特别注意的是,很多人认为编译器会用 0 来初始化变量,这是错误的(而且这样很不利于查找错误)。

        (2) 通过函数指针调用函数时,会通过检查栈指针验证函数调用的匹配性。(防止原形不匹配)

        (3) 函数返回前检查栈指针,确认未被修改。(防止越界访问和原形不匹配,与第二项合在一起可大致模拟帧指针省略 FPO )

        通常 /GZ 选项会造成 Debug 版出错而 Release 版正常的现象,因为 Release 版中未初始化的变量是随机的,这有可能使指针指向一个有效地址而掩盖了非法访问。

        除此之外,/Gm /GF 等选项造成错误的情况比较少,而且他们的效果显而易见,比较容易发现。

       三、怎样“调试” Release 版的程序

        遇到 Debug 成功但 Release 失败,显然是一件很沮丧的事,而且往往无从下手。如果你看了以上的分析,结合错误的具体表现,很快找出了错误,固然很好。但如果一时找不出,以下给出了一些在这种情况下的策略。

        1. 前面已经提过,Debug 和 Release 只是一组编译选项的差别,实际上并没有什么定义能区分二者。我们可以修改 Release 版的ucos iii源码分析编译选项来缩小错误范围。如上所述,可以把 Release 的选项逐个改为与之相对的 Debug 选项,如 /MD 改为 /MDd、/O1 改为 /Od,或运行时间优化改为程序大小优化。注意,一次只改一个选项,看改哪个选项时错误消失,再对应该选项相关的错误,针对性地查找。这些选项在 Project\Settings... 中都可以直接通过列表选取,通常不要手动修改。由于以上的分析已相当全面,这个方法是最有效的。

        2. 在编程过程中就要时常注意测试 Release 版本,以免最后代码太多,时间又很紧。

        3. 在 Debug 版中使用 /W4 警告级别,这样可以从编译器获得最大限度的错误信息,比如 if( i =0 )就会引起 /W4 警告。不要忽略这些警告,通常这是你程序中的 Bug 引起的。但有时 /W4 会带来很多冗余信息,如 未使用的函数参数 警告,而很多消息处理函数都会忽略某些参数。我们可以用

        #progma warning(disable: ) //禁止

        //...

        #progma warning(default: ) //重新允许

        来暂时禁止某个警告,或使用

        #progma warning(push, 3) //设置警告级别为 /W3

        //...

        #progma warning(pop) //重设为 /W4

        来暂时改变警告级别,有时你可以只在认为可疑的那一部分代码使用 /W4。

        4.你也可以像 Debug 一样调试你的 Release 版,只要加入调试符号。在 Project/Settings... 中,选中 Settings for "Win Release",选中 C/C++ 标签,Category 选 General,Debug Info 选 Program Database。再在 Link 标签 Project options 最后加上 "/OPT:REF" (引号不要输)。这样调试器就能使用 pdb 文件中的调试符号。但调试时你会发现断点很难设置,变量也很难找到——这些都被优化过了。不过令人庆幸的是,Call Stack 窗口仍然工作正常,即使帧指针被优化,栈信息(特别是返回地址)仍然能找到。这对定位错误很有帮助。

VC DEBUG和 release区别

       ç¨‹åºçš„debug版本:含调试信息(比如行号),所以所得到的exe文件很大

       è€Œä¸”得到可执行文件不进行优化

       ç¨‹åºçš„release版本:(一般)不包含调试信息(当然有些编译器可以做一些选项来包含调试信息),

       æ‰€ä»¥æ‰€å¾—到的exe文件比debug版本小的多了

       è€Œä¸”一般编译器可能还自动对程序进行了优化

       release版本:速度快

       å ç”¨ç©ºé—´å°

       æ‰€ä»¥æ‰å«å‘布版本

release和debugrelease和debug的区别

       关于release和debug,release和debug的区别这个很多人还不知道,今天来为大家解答以上的问题,现在让我们一起来看看吧!

       1、一、Debug 和 Release 编译方式的本质区别Debug 通常称为调试版本,它包含调试信息,并且不作任何优化,便于程序员调试程序。

       2、Release 称为发布版本,它往往是进行了各种优化,使得程序在代码大小和运行速度上都是最优的,以便用户很好地使用。

       3、Debug 和 Release 的真正秘密,在于一组编译选项。

       4、下面列出了分别针对二者的选项(当然除此之外还有其他一些,如/Fd /Fo,但区别并不重要,通常他们也不会引起 Release 版错误,在此不讨论)Debug 版本:/MDd /MLd 或 /MTd 使用 Debug runtime library(调试版本的运行时刻函数库)/Od 关闭优化开关/D "_DEBUG" 相当于 #define _DEBUG,打开编译调试代码开关(主要针对assert函数)/ZI 创建 Edit and continue(编辑继续)数据库,这样在调试过程中如果修改了源代码不需重新编译/GZ 可以帮助捕获内存错误/Gm 打开最小化重链接开关,减少链接时间Release 版本:/MD /ML 或 /MT 使用发布版本的运行时刻函数库/O1 或 /O2 优化开关,使程序最小或最快/D "NDEBUG" 关闭条件编译调试代码开关(即不编译assert函数)/GF 合并重复的字符串,并将字符串常量放到只读内存,防止被修改实际上,Debug 和 Release 并没有本质的界限,他们只是一组编译选项的集合,编译器只是按照预定的选项行动。

       5、事实上,我们甚至可以修改这些选项,从而得到优化过的调试版本或是带跟踪语句的发布版本。

       6、二、哪些情况下 Release 版会出错有了上面的介绍,我们再来逐个对照这些选项看看 Release 版错误是怎样产生的1. Runtime Library:2. 优化:这类错误主要有以下几种:(1) 帧指针(Frame Pointer)省略(简称 FPO ):在函数调用过程中,所有调用信息(返回地址、参数)以及自动变量都是放在栈中的。

       7、若函数的声明与实现不同(参数、返回值、调用方式),就会产生错误————但 Debug 方式下,栈的访问通过 EBP 寄存器保存的地址实现,如果没有发生数组越界之类的错误(或是越界“不多”),函数通常能正常执行;Release 方式下,优化会省略 EBP 栈基址指针,这样通过一个全局指针访问栈就会造成返回地址错误是程序崩溃。

       8、C++ 的强类型特性能检查出大多数这样的错误,但如果用了强制类型转换,就不行了。

       9、你可以在 Release 版本中强制加入 /Oy- 编译选项来关掉帧指针省略,以确定是否此类错误。

       、(2) volatile 型变量:volatile 告诉编译器该变量可能被程序之外的未知方式修改(如系统、其他进程和线程)。

       、(3) 变量优化:优化程序会根据变量的使用情况优化变量。

       、例如,函数中有一个未被使用的变量,在 Debug 版中它有可能掩盖一个数组越界,而在 Release 版中,这个变量很可能被优化调,此时数组越界会破坏栈中有用的数据。

       、当然,实际的情况会比这复杂得多。

       、与此有关的错误有:3. _DEBUG 与 NDEBUG :当定义了 _DEBUG 时,assert() 函数会被编译,而 NDEBUG 时不被编译。

       、除此之外,VC++中还有一系列断言宏。

       、这包括:ANSI C 断言 void assert(int expression );C Runtime Lib 断言 _ASSERT( booleanExpression );_ASSERTE( booleanExpression );MFC 断言 ASSERT( booleanExpression );VERIFY( booleanExpression );ASSERT_VALID( pObject );ASSERT_KINDOF( classname, pobject );ATL 断言 ATLASSERT( booleanExpression );此外,TRACE() 宏的编译也受 _DEBUG 控制。

       、4. /GZ 选项:这个选项会做以下这些事(1) 初始化内存和变量。

       、(2) 通过函数指针调用函数时,会通过检查栈指针验证函数调用的匹配性。

       、(防止原形不匹配)(3) 函数返回前检查栈指针,确认未被修改.三、怎样“调试” Release 版的程序1. 前面已经提过,Debug 和 Release 只是一组编译选项的差别,实际上并没有什么定义能区分二者。

       、我们可以修改 Release 版的编译选项来缩小错误范围。

       、如上所述,可以把 Release 的选项逐个改为与之相对的 Debug 选项,如 /MD 改为 /MDd、/O1 改为 /Od,或运行时间优化改为程序大小优化。

       、注意,一次只改一个选项,看改哪个选项时错误消失,再对应该选项相关的错误,针对性地查找。

       、这些选项在 ProjectSettings... 中都可以直接通过列表选取,通常不要手动修改。

       、由于以上的分析已相当全面,这个方法是最有效的。

       、2.你也可以像 Debug 一样调试你的 Release 版,只要加入调试符号。

       、在 Project/Settings... 中,选中 Settings for "Win Release",选中 C/C++ 标签,Category 选General,Debug Info 选 Program Database。

       、再在 Link 标签 Project options 最后加上 "/OPT:REF" (引号不要输)。

Debug和Release的区别

       ã€€ã€€Debug和Release区别

       ã€€ã€€VC下Debug和Release区别

       ã€€ã€€æœ€è¿‘写代码过程中,发现 Debug 下运行正常,Release 下就会出现问题,百思不得其解,而Release 下又无法进行调试,于是只能采用printf方式逐步定位到问题所在处,才发现原来是给定的一个数组未初始化,导致后面处理异常。网上查找了些资料,在这 罗列汇总下,做为备忘~

       ã€€ã€€ä¸€ã€Debug 和 Release 的区别

       ã€€ã€€Debug 通常称为调试版本,它包含调试信息,并且不作任何优化,便于程序员调试程序。Release 称为发布版本,它往往是进行了各种优化,使得程序在代码大小和运行速度上都是最优的,以便用户很好地使用。

       ã€€ã€€Debug 和 Release 的真正区别,在于一组编译选项。

       ã€€ã€€Debug 版本

       ã€€ã€€å‚æ•° 含义

       ã€€ã€€/MDd /MLd 或 /MTd 使用 Debug runtime library(调试版本的运行时刻函数库)

       ã€€ã€€/Od 关闭优化开关

       ã€€ã€€/D "_DEBUG" 相当于 #define _DEBUG,打开编译调试代码开关(主要针对assert函数)

       ã€€ã€€/ZI

       ã€€ã€€åˆ›å»º Edit and continue(编辑继续)数据库,这样在调试过程中如果修改了源代码不需重新编译

       ã€€ã€€GZ 可以帮助捕获内存错误

       ã€€ã€€

       ã€€ã€€Release 版本 参数含义

       ã€€ã€€/MD /ML 或 /MT 使用发布版本的运行时刻函数库

       ã€€ã€€/O1 或 /O2 优化开关,使程序最小或最快

       ã€€ã€€/D "NDEBUG" 关闭条件编译调试代码开关(即不编译assert函数)

       ã€€ã€€/GF 合并重复的字符串,并将字符串常量放到只读内存,防止被修改

       ã€€ã€€Debug 和 Release 并没有本质的界限,他们只是一组编译选项的集合,编译器只是按照预定的选项行动。

       ã€€ã€€

       ã€€ã€€ã€€ã€€1. 变量。

       ã€€ã€€å¤§å®¶éƒ½çŸ¥é“,debug跟release在初始化变量时所做的操作是不同的,debug是将每个字节位都赋成0xcc(注1),而release的赋值近 似于随机(我想是直接从内存中分配的,没有初始化过)。这样就明确了,如果你的程序中的某个变量没被初始化就被引用,就很有可能出现异常:用作控制变量将 导致流程导向不一致;用作数组下标将会使程序崩溃;更加可能是造成其他变量的不准确而引起其他的错误。所以在声明变量后马上对其初始化一个默认的值是最简 单有效的办法,否则项目大了你找都没地方找。代码存在错误在debug方式下可能会忽略而不被察觉到,如debug方式下数组越界也大多不会出错,在 release中就暴露出来了,这个找起来就比较难了:( 还是自己多加注意吧

       ã€€ã€€å‘µå‘µï¼Œå°±æ˜¯æˆ‘犯的问题~~

       ã€€ã€€2. 自定义消息的消息参数。

       ã€€ã€€MFC为我们提供了很好的消息机制,更增加了自定义消息,好处我就不用多说了。这也存在debug跟release的问题吗?答案是肯定的。在自定义消息 的函数体声明时,时常会看到这样的写法:afx_msg LRESULT OnMessageOwn(); Debug情况下一般不会有任何问题,而当你在Release下且多线程或进程间使用了消息传递时就会导致无效句柄之类的错误。导致这个错误直接原因是消 息体的参数没有添加,即应该写成:afx_msg LRESULT OnMessageOwn(WPARAM wparam, LPARAM lparam); (注2)

       ã€€ã€€3. release模式下不出错,但debug模式下报错。

       ã€€ã€€è¿™ç§æƒ…况下大多也是因为代码书写不正确引起的,查看MFC的源码,可以发现好多ASSERT的语句(断言),这个宏只是在debug模式下才有效,那么就 清楚了,release版不报错是忽略了错误而不是没有错误,这可能存在很大的隐患,因为是Debug模式下,比较方便调试,好好的检查自己的代码,再此 就不多说了。

       ã€€ã€€4. ASSERT, VERIFY, TRACE..........调试宏

       ã€€ã€€è¿™ç§æƒ…况很容易解释。举个例子:请在VC下输入ASSERT然后选中按F跳到宏定义的地方,这里你就能够发现Debug中ASSERT要执行 AfxAssertFailedLine,而Release下的宏定义却为"#define ASSERT(f) ((void)0)"。所以注意在这些调试宏的语句不要用程序相关变量如i++写操作的语句。VERIFY是个例外,"#define VERIFY(f) ((void)(f))",即执行,这里的作用就不多追究了,有兴趣可自己研究:)。

       ã€€ã€€æ€»ç»“:

       ã€€ã€€Debug与Release不同的问题在刚开始编写代码时会经常发生,%是因为你的代码书写错误而导致的,所以不要动不动就说系统问题或编译器问题, 努力找找自己的原因才是根本。我从前就常常遇到这情况,经历过一次次的教训后我就开始注意了,现在我所写过的代码我已经好久没遇到这种问题了。下面是几个 避免的方面,即使没有这种问题也应注意一下:

       ã€€ã€€1. 注意变量的初始化,尤其是指针变量,数组变量的初始化(很大的情况下另作考虑了)。

       ã€€ã€€2. 自定义消息及其他声明的标准写法

       ã€€ã€€3. 使用调试宏时使用后最好注释掉

       ã€€ã€€4. 尽量使用try - catch(...)

       ã€€ã€€5. 尽量使用模块,不但表达清楚而且方便调试。

       ã€€ã€€æ³¨1:

       ã€€ã€€debug版初始化成0xcc是因为0xcc在x下是一条int 3单步中断指令,这样程序如果跑飞了遇到0xcc就会停下来,这和单片机编程时一般将没用的代码空间填入jmp 语句是一样地转贴于:计算机二级考试_考试大【责编:drfcy 纠错】

       ã€€ã€€[VC]DEBUG和RELEASE年月日 星期日 下午 : I. 内存分配问题

       ã€€ã€€

       ã€€ã€€1. 变量未初始化。下面的程序在debug中运行的很好。

       ã€€ã€€

       ã€€ã€€thing * search(thing * something)

       ã€€ã€€BOOL found;

       ã€€ã€€for(int i = 0; i < whatever.GetSize(); i++)

       ã€€ã€€{

       ã€€ã€€if(whatever[i]->field == something->field)

       ã€€ã€€{ /* found it */

       ã€€ã€€found = TRUE;

       ã€€ã€€break;

       ã€€ã€€} /* found it */

       ã€€ã€€}

       ã€€ã€€if(found)

       ã€€ã€€return whatever[i];

       ã€€ã€€else

       ã€€ã€€return NULL;

       ã€€ã€€è€Œåœ¨release中却不行,因为debug中会自动给变量初始化found=FALSE,而在release版中则不会。所以尽可能的给变量、类或结构初始化。

       ã€€ã€€

       ã€€ã€€2. 数据溢出的问题

       ã€€ã€€

       ã€€ã€€å¦‚:char buffer[];

       ã€€ã€€int counter;

       ã€€ã€€

       ã€€ã€€lstrcpy(buffer, "abcdefghik");

       ã€€ã€€

       ã€€ã€€åœ¨debug版中buffer的NULL覆盖了counter的高位,但是除非counter>M,什么问题也没有。但是在release版 中,counter可能被放在寄存器中,这样NULL就覆盖了buffer下面的空间,可能就是函数的返回地址,这将导致ACCESS ERROR。

       ã€€ã€€

       ã€€ã€€3. DEBUG版和RELEASE版的内存分配方式是不同的 。如果你在DEBUG版中申请 ele 为 6*sizeof(DWORD)=bytes,实际上分配给你的是bytes(debug版以bytes为单位分配), 而在release版,分配给你的就是bytes(release版以8bytes为单位),所以在debug版中如果你写ele[6],可能不会有 什么问题,而在release版中,就有ACCESS VIOLATE。

       ã€€ã€€

       ã€€ã€€II. ASSERT和VERIFY

       ã€€ã€€

       ã€€ã€€1. ASSERT在Release版本中是不会被编译的。

       ã€€ã€€

       ã€€ã€€ASSERT宏是这样定义的

       ã€€ã€€

       ã€€ã€€#ifdef _DEBUG

       ã€€ã€€#define ASSERT(x) if( (x) == 0) report_assert_failure()

       ã€€ã€€#else

       ã€€ã€€#define ASSERT(x)

       ã€€ã€€#endif

       ã€€ã€€å®žé™…上复杂一些,但无关紧要。假如你在这些语句中加了程序中必须要有的代码

       ã€€ã€€æ¯”如

       ã€€ã€€

       ã€€ã€€ASSERT(pNewObj = new CMyClass);

       ã€€ã€€

       ã€€ã€€pNewObj->MyFunction();

       ã€€ã€€

       ã€€ã€€è¿™ç§æ—¶å€™Release版本中的pNewObj不会分配到空间

       ã€€ã€€

       ã€€ã€€æ‰€ä»¥æ‰§è¡Œåˆ°ä¸‹ä¸€ä¸ªè¯­å¥çš„时候程序会报该程序执行了非法操作的错误。这时可以用VERIFY :

       ã€€ã€€

       ã€€ã€€#ifdef _DEBUG

       ã€€ã€€#define VERIFY(x) if( (x) == 0) report_assert_failure()

       ã€€ã€€#else

       ã€€ã€€#define VERIFY(x) (x)

       ã€€ã€€#endif

       ã€€ã€€è¿™æ ·çš„话,代码在release版中就可以执行了。

       ã€€ã€€

       ã€€ã€€III. 参数问题:

       ã€€ã€€

       ã€€ã€€è‡ªå®šä¹‰æ¶ˆæ¯çš„处理函数,必须定义如下:

       ã€€ã€€

       ã€€ã€€afx_msg LRESULT OnMyMessage(WPARAM, LPARAM);

       ã€€ã€€

       ã€€ã€€è¿”回值必须是HRESULT型,否则Debug会过,而Release出错

       ã€€ã€€

       ã€€ã€€IV. 内存分配

       ã€€ã€€

       ã€€ã€€ä¿è¯æ•°æ®åˆ›å»ºå’Œæ¸…除的统一性:如果一个DLL提供一个能够创建数据的函数,那么这个DLL同时应该提供一个函数销毁这些数据。数据的创建和清除应该在同一个层次上。

       ã€€ã€€

       ã€€ã€€V. DLL的灾难

       ã€€ã€€

       ã€€ã€€äººä»¬å°†ä¸åŒç‰ˆæœ¬DLL混合造成的不一致性形象的称为 “动态连接库的地狱“(DLL Hell) ,甚至微软自己也这么说

       ã€€ã€€

       ã€€ã€€å¦‚果你的程序使用你自己的DLL时请注意:

       ã€€ã€€

       ã€€ã€€1. 不能将debug和release版的DLL混合在一起使用。debug都是debug版,release版都是release版。

       ã€€ã€€

       ã€€ã€€è§£å†³åŠžæ³•æ˜¯å°†debug和release的程序分别放在主程序的debug和release目录下

       ã€€ã€€

       ã€€ã€€

       ã€€ã€€2. 千万不要以为静态连接库会解决问题,那只会使情况更糟糕。

       ã€€ã€€

       ã€€ã€€VI. RELEASE板中的调试 :

       ã€€ã€€

       ã€€ã€€1. 将ASSERT() 改为 VERIFY() 。找出定义在"#ifdef _DEBUG"中的代码,如果在RELEASE版本中需要这些代码请将他们移到定义外。查找TRACE(...)中代码,因为这些代码在RELEASE中 也不被编译。 请认真检查那些在RELEASE中需要的代码是否并没有被便宜。

       ã€€ã€€

       ã€€ã€€2. 变量的初始化所带来的不同,在不同的系统,或是在DEBUG/RELEASE版本间都存在这样的差异,所以请对变量进行初始化。

       ã€€ã€€

       ã€€ã€€3. 是否在编译时已经有了警告?请将警告级别设置为3或4,然后保证在编译时没有警告出现.

       ã€€ã€€

       ã€€ã€€VII. 将Project Settings" 中 "C++/C " 项目下优化选项改为Disbale(Debug)。编译器的优化可能导致许多意想不到的错误

       ã€€ã€€

       ã€€ã€€1. 此外对RELEASE版本的软件也可以进行调试,请做如下改动:

       ã€€ã€€

       ã€€ã€€åœ¨"Project Settings" 中 "C++/C " 项目下设置 "category" 为 "General" 并且将"Debug Info"设置为 "Program Database"。

       ã€€ã€€

       ã€€ã€€åœ¨"Link"项目下选中"Generate Debug Info"检查框。

       ã€€ã€€

       ã€€ã€€"Rebuild All"

       ã€€ã€€

       ã€€ã€€å¦‚此做法会产生的一些限制:

       ã€€ã€€

       ã€€ã€€æ— æ³•èŽ·å¾—在MFC DLL中的变量的值。

       ã€€ã€€

       ã€€ã€€å¿…须对该软件所使用的所有DLL工程都进行改动。

Java并发必会,深入剖析Semaphore源码

       在深入理解Java并发编程时,必不可少的是对Semaphore源码的剖析。本文将带你探索这一核心组件,通过实践和源码解析,掌握其限流和共享锁的本质。Semaphore,中文名信号量,就像一个令牌桶,任务执行前需要获取令牌,处理完毕后归还,确保资源访问的有序进行。

       首先,Semaphore主要有acquire()和release()两个方法。acquire()负责获取许可,若许可不足,任务会被阻塞,直到有许可可用。release()用于释放并归还许可,确保资源释放后,其他任务可以继续执行。一个典型的例子是,如果一个线程池接受个任务,但Semaphore限制为3,那么任务将按每3个一组执行,确保系统稳定性。

       Semaphore的源码实现巧妙地结合了AQS(AbstractQueuedSynchronizer)框架,通过Sync同步变量管理许可数量,公平锁和非公平锁的实现方式有所不同。公平锁会优先处理队列中的任务,而非公平锁则按照获取许可的顺序进行。

       acquire()方法主要调用AQS中的acquireSharedInterruptibly(),并进一步通过tryReleaseShared()进行许可更新,公平锁与非公平锁的区别在于判断队列中是否有前置节点。release()方法则调用releaseShared(),更新许可数量。

       Semaphore的简洁逻辑在于,AQS框架负责大部分并发控制,子类只需实现tryReleaseShared()和tryAcquireShared(),专注于许可数量的管理。欲了解AQS的详细流程,可参考之前的文章。

       最后,了解了Semaphore后,我们还将继续探索共享锁CyclicBarrier的实现,敬请期待下篇文章。

ionic debug 和release 的区别

       Debug和Release区别

       VC下Debug和Release区别

       æœ€è¿‘写代码过程中,发现 Debug 下运行正常,Release 下就会出现问题,百思不得其解,而Release 下又无法进行调试,于是只能采用printf方式逐步定位到问题所在处,才发现原来是给定的一个数组未初始化,导致后面处理异常。网上查找了些资料,在这 罗列汇总下,做为备忘~

       ä¸€ã€Debug 和 Release 的区别

       Debug 通常称为调试版本,它包含调试信息,并且不作任何优化,便于程序员调试程序。Release 称为发布版本,它往往是进行了各种优化,使得程序在代码大小和运行速度上都是最优的,以便用户很好地使用。

       Debug 和 Release 的真正区别,在于一组编译选项。

       Debug 版本

       å‚æ•° 含义

       /MDd /MLd 或 /MTd 使用 Debug runtime library(调试版本的运行时刻函数库)

       /Od 关闭优化开关

       /D "_DEBUG" 相当于 #define _DEBUG,打开编译调试代码开关(主要针对assert函数)

       /ZI

       åˆ›å»º Edit and continue(编辑继续)数据库,这样在调试过程中如果修改了源代码不需重新编译

       GZ 可以帮助捕获内存错误

       Release 版本 参数含义

       /MD /ML 或 /MT 使用发布版本的运行时刻函数是忽略了

了解Debug和Release的区别

       在编程领域,了解Debug和Release的区别是至关重要的。在VC++中,编译有两种模式:Release Build和Debug Build,它们各自具有不同的特点和用途。Release Build模式不对源代码进行调试,不考虑MFC的诊断宏,使用MFC Release库,对应用程序的运行速度进行了优化。相比之下,Debug Build模式则允许对源代码进行调试,可以定义和使用MFC的诊断宏,采用MFC Debug库,但速度没有优化。

       在Debug模式下开发应用程序是推荐的,因为它允许开发人员在运行时捕获并修正错误,从而提高代码的质量和稳定性。而发布应用程序时,通常使用Release模式,因为这会提供更快的执行速度,以确保用户获得流畅的体验。

       在VC++中,通过选择"Build->Set Active Configuration"菜单选项,可以设置当前程序的模式为Release版本或Debug版本。这使得开发人员能够灵活地在开发和发布阶段之间切换。

       综上所述,了解Debug和Release的区别对于有效的应用程序开发至关重要。在开发过程中使用Debug模式以确保代码质量,而在发布阶段选择Release模式以提供最佳性能。正确理解并应用这些模式,可以显著提高开发效率和应用程序质量。

相关栏目:休闲