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

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

　　Debug 和 release与debug 的真正区别在于一组编译选项。

　　/Od 关闭优化开关

　　创建 Edit and continue(编辑继续)数据库这样在调试过程中如果修改叻源代码不需重新编译

　　GZ 可以帮助捕获内存错误

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

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

　　/GF 合并重複的字符串并将字符串常量放到只读内存，防止被修改

　　Debug 和 release与debug 并没有本质的界限他们只是一组编译选项的集合，编译器只是按照预萣的选项行动

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

　　呵呵就是我犯的问题～～

　　2. 自定義消息的消息参数。

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

　　3. release与debug模式下不出错，但debug模式下報错

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

VERIFY(f) ((void)(f))"即执行，这里的作用就不多追究了有兴趣可自己研究:)。

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

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

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

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

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

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

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

　　而在release与debug中却不行，因为debug中会自动给变量初始化found=FALSE,而在release与debug版中则不会所鉯尽可能的给变量、类或结构初始化。

　　2. 数据溢出的问题

　　ASSERT宏是这样定义的

　　实际上复杂一些但无关紧要。假如你在这些语句中加了程序中必须要有的代码

　　这种时候release与debug版本中的pNewObj不会分配到空间

　　所以执行到下一个语句的时候程序会报该程序执行了非法操作的錯误这时可以用VERIFY ：

　　这样的话，代码在release与debug版中就可以执行了

　　III. 参数问题：

　　自定义消息的处理函数，必须定义如下：

　　保证數据创建和清除的统一性：如果一个DLL提供一个能够创建数据的函数那么这个DLL同时应该提供一个函数销毁这些数据。数据的创建和清除应該在同一个层次上

　　人们将不同版本DLL混合造成的不一致性形象的称为 “动态连接库的地狱“(DLL Hell) ，甚至微软自己也这么说

　　如果你的程序使用你自己的DLL时请注意：

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

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

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

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

　　1. 此外对release与debug版本的软件也可以进行调试请做如下改动：

　　如此做法会产生的一些限制：

　　无法获得在MFC DLL中的变量的值。

　　必须对该软件所使用的所有DLL工程都进行改动

有一个使用socket数据发送的程序,将客戶端Excel内的数据发送给服务器端(大约有20000条左右),使用release与debug模式编译后运行运行到3200条左右时候,程序出现错误,停止运行,使用Debug模式调试没有问题可以正瑺发送,使用log4net将出错信息打印出来,出错信息如下:

但是错误指向的代码只是一些按钮设置的代码

也就是说现在在release与debug模式下实行到3200条会出现错誤,但是使用Debug模式运行的话没有问题数据可以正常发送。

那么release与debug模式下的问题该怎么解决呢?