Debug 版本 vs Release版本

 

一、C  Run-time Library

　　Win32程序（使用Windows标准库），如果是 /MD 编译的程序，那么使用Depends.exe会发现其中需要 USER32.DLL、KERNEL32.DLL、GDI32.DLL、MSVCR80.DLL 等文件支持。像前３个DLL文件是Windows系统自带的，我们不用去考虑它（除非你在程序中使用的API，windows版本不支持）。 MSVCR80.DLL 需要注意一下的，

  

 

　　如果一个程序，不想再放一个 MSVCR80.DLL 文件在安装包中，可用 /MT 编译程序（静态连接）。这时就不需要这个DLL文件了．（如果有多个程序模块，还是把 MSVCR80.DLL 加上吧，这样也可减少各模块的体积。） 如果程序中用到了 MFC 、ATL， 可以修改项目属性配置中的“MFC、ATL的使用方式”。

 

=====================================================================================================================

 

二、Debug 和 Release 编译方式的本质区别

　　Debug 通常称为调试版本，它包含调试信息，并且不作任何优化，便于程序员调试程序。

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

 

三、编译选项说明

　　　　　　C 运行时库                       　　　　　　　　　　　　 库文件

---------------------------------------------------------------------------------------------------------------------------
　　ML       Single thread(static link)             　　　　　　　   libc.lib
　　MLd     Debug single thread(static link)         　　　　     libcd.lib
　　MT      MultiThread(static link)             　　　　　　　　　libcmt.lib
　　MTd    Debug multiThread(static link)            　　　　     libcmtd.lib
     MD      MultiThread(dynamic link)             　　　　　　　  msvert.lib
     MDd     Debug multiThread(dynamic link)                       msvertd.lib

1、各种C 运行时库的区别
   （1)   静态链接的单线程库
　　静态链接的单线程库只能用于单线程的应用程序，C 运行时库的目标代码最终被编译在应用程序的二进制文件中。通过 /ML 编译选项可以设置 Visual C++ 使用静态链接的单线程库。
    (2)   静态链接的多线程库
　　静态链接的多线程库的目标代码也最终被编译在应用程序的二进制文件中，但是它可以在多线程程序中使用。通过 /MT 编译选项可以设置 Visual C++ 使用静态链接的多线程库。
   (3)  动态链接的运行时库
　　动态链接的运行时库将所有的 C 库函数保存在一个单独的动态链接库 MSVCRTxx.DLL 中， MSVCRTxx.DLL 处理了多线程问题。使用 /MD 编译选项可以设置 Visual C++ 使用动态链接的运行时库。

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

     /MD 、 /ML 或 /MT 分别对应。

　　Debug 版本的 Runtime Library 包含了调试信息，并采用了一些保护机制以帮助发现错误，加强了对错误的检测，因此在运行性能方面比不上Release 版本。

下面是msdn关于Visual C++ 编译器选项的说明：
　　这些选项选择单线程或多线程运行时例程，指示多线程模块是否为 DLL，并选择运行时库的发布版本或调试版本。
　　选项    　　　　　　　　　　　　　　　　　　　　　　 说明

------------------------------------------------------------------------------------------------------------------------------------------------------
　　/MD     　　　　　　　　　定义 _MT 和 _DLL 以便同时从标准 .h 文件中选择运行时例程的多线程特定版本和 DLL 特定版本。

　　　　　　　　　　　　　　　此选项还使编译器将库名 MSVCRT.lib 放入 .obj 文件中。用此选项编译的应用程序静态链接到 MSVCRT.lib。

　　　　　　　　　　　　　　　该库提供允许链接器解析外部引用的代码层。实际工作代码包含在 MSVCR71.DLL 中，

　　　　　　　　　　　　　　　该库必须在运行时对于与 MSVCRT.lib 链接的应用程序可用。
　　　　　　　　　　　　　　　当在定义了 _STATIC_CPPLIB (/D_STATIC_CPPLIB) 的情况下使用 /MD 时，

　　　　　　　　　　　　　　　它将导致应用程序通过静态多线程标准C++ 库 (libcpmt.lib) 而非动态版本 (msvcprt.lib) 进行链接，

　　　　　　　　　　　　　　　同时仍通过 msvcrt.lib 动态链接到主 CRT。

　　　　　　　　　　　　　　　　-----------------------------------------------------------------------------------------------------------------
　　/MDd     　　　　　　　　定义 _DEBUG、_MT 和 _DLL，以便从标准 .h 文件中选择运行时例程的调试多线程特定版本和 DLL 特定版本。

　　　　　　　　　　　　　　 它还使编译器将库名 MSVCRTD.lib 放入 .obj 文件中。

　　　　　　　　　　　　　　　　-----------------------------------------------------------------------------------------------------------------
　　/ML     　　　　　　　　 使编译器将库名 LIBC.lib 放入 .obj 文件中，以便链接器使用 LIBC.lib 解析外部符号。

　　　　　　　　　　　　　　这是编译器的默认操作。 LIBC.lib 不提供多线程支持。

　　　　　　　　　　　　　　　　-----------------------------------------------------------------------------------------------------------------
　　/MLd    　　　　　　　　定义 _DEBUG 并使编译器将库名 LIBCD.lib 放入 .obj 文件中，以便链接器使用 LIBCD.lib 解析外部符号。

　　　　　　　　　　　　　　LIBCD.lib 不提供多线程支持。

　　　　　　　　　　　　　　　   ----------------------------------------------------------------------------------------------------------------
　　/MT     　　　　　　　　定义 _MT，以便从标准头 (.h) 文件中选择运行时例程的多线程特定版本。

　　　　　　　　　　　　　　此选项还使编译器将库名 LIBCMT.lib 放入 .obj 文件中，以便链接器使用 LIBCMT.lib 解析外部符号。

　　　　　　　　　　　　　　创建多线程程序需要 /MT     或 /MD（或它们的调试等效选项 /MTd 或 /MDd）。

　　　　　　　　　　　　　　　  -----------------------------------------------------------------------------------------------------------------
　　/MTd     　　　　　　　　定义 _DEBUG 和 _MT。定义 _MT 会导致从标准 .h 文件中选择运行时例程的多线程特定版本。

　　　　　　　　　　　　　　 此选项还使编译器将库名 LIBCMTD.lib 放入 .obj 文件中，以便链接器使用 LIBCMTD.lib 解析外部符号。

　　　　　　　　　　　　　　 创建多线程程序需要 /MTd或 /MDd（或它们的非调试等效选项 /MT 或 MD）。

　　　　　　　　　　　　　       -----------------------------------------------------------------------------------------------------------------
　　/LD     　　　　　　　　  创建 DLL。将 /DLL 选项传递到链接器。链接器查找 DllMain 函数，但并不需要该函数。

　　　　　　　　　　　　　　 如果没有编写 DllMain 函数，链接器将插入返回 TRUE 的 DllMain 函数。链接 DLL 启动代码。

　　　　　　　　　　　　　　 如果命令行上未指定导出 (.exp) 文件，则创建导入库(.lib)；将导入库链接到调用您的 DLL 的应用程序。

　　　　　　　　　　　　　　 将 /Fe 解释为命名 DLL 而不是 .exe 文件；默认程序名成为基名称.dll 而不是基名称.exe。

　　　　　　　　　　　　　　 如果还未显式指定 /M 选项之一，则将默认运行时库支持更改为 /MT。

　　　　　　　　　　　　         -----------------------------------------------------------------------------------------------------------------
　　/LDd     　　　　　　　　 创建调试 DLL。定义 _DEBUG。

 

　　  警告   不要混合使用运行时库的静态版本和动态版本。在一个进程中有多个运行时库副本会导致问题，因为副本中的静态数据不与其他副本共享。链接器禁止在 .exe 文件内部既使用静态版本又使用动态版本链接，但您仍可以使用运行时库的两个（或更多）副本。例如，当与用动态 (DLL) 版本的运行时库链接的 .exe 文件一起使用时，用静态（非 DLL）版本的运行时库链接的动态链接库可能导致问题。（还应该避免在一个进程中混合使用这些库的调试版本和非调试版本）。

 

 

四、哪些情况下 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（） 违反了断言的思想，不能使程序代码和调试代码完全分离，最终可能会带来很多麻烦。因此，专家们建议尽量少用这个宏。

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

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

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

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

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

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