original[
Http://blog.9cbs.net/welcome_ck/archive/2004/12/29/233204.aspx
]
1. DEBUG and RELEASE have any difference, why do you want to use the Release version! 2. How to convert Debug into the Release debug version including debugging information, so much more than the release version (possibly large hundred k to number m). As for whether DLL support is required, mainly look at the compilation option you use. If ATL is based on ATL, the debug and release versions are similar to the DLL. If the compilation option used is to use the MFC dynamic library, you need MFC42D.DLL support, and the Release version requires MFC42.dll support. Release Build does not debug the source code, regardless of the MFC diagnostic macro, use the MFC Release library, the compile ten pairs of applications can be optimized, while Debug Build is just reversed, it allows debugging of the source code, can be defined and Using the MFC diagnostic macro, the MFC Debug library is used, and the speed is not optimized. I. The essence difference between Debug and Release Compile Mode DEBUG is often referred to as a debug version, which contains debugging information, and does not make any optimization, which is convenient for programmer debugging. Release is called publishing, which is often optimized so that the program is optimal in code size and running speed so that users are well used. Debug and Release True Secrets lies in a set of compilation options. The following is listed below (otherwise additional, such as / fd / fo, but the difference is not important, usually do not cause the Release version error, here no discussion) Debug version : / MDD / MLD or / MTD Using Debug Runtime Library (debug version runtime function library) / OD close optimization switch / D "_debug" is equivalent to #define _debug, open the compile debug code switch (mainly for Assert functions) / zi Create Edit and Continue Database, this is modified in debugging If you modify the source code No need to recompile / GZ can help capture memory error / GM to open minimize heavy link switch, reduce link time Release version: / md / ML or / MT uses the release version of the runtime function library / O1 or / O2 optimization switch, minimizing the program smallest or the fastest / D "NDEBUG" closes the debug code switch (ie, does not compile the Assert function) / GF merged characters String, and put string constants in read-only memory, preventing modifications, DEBUG, and Release have no essential boundaries, they are just a set of compile options, the compiler is just a scheduled action action. In fact, we can even modify these options to get an optimized debug version or a publishing version with tracking statements. Second, where the release version has an error with the above introduction, let's take a look at these options to see how the Release version is generated. 1. Runtime library: Link which runtime function library usually only affects the performance of the program . The debug version of Runtime Library contains debugging information and has some protection mechanism to help find errors, so performance is not as good as release.
The Runtime Library provided by the compiler is usually very stable and will not cause the Release version of the error; It should be pointed out that if Debug is wrong, even if Release is normal, the program is definitely a bug, but it may be that the release version of the RELASE version is not expressed. 2. Optimization: This is the main reason for errors, because the source program is basically directly translated, while the compiler will make a series of assumptions after opening optimization. Such errors have the following: (1) Frame Pointer omit (referlateral): In the function call, all call information (return addresses, parameters), and automatic variables are placed in the stack. If the declaration of the function is different (parameters, return value, call mode), an error is generated --- but DEBUG mode, the stack is implemented through the address saved by the EBP register, and if there is no error, the error occurred (Or the crossover "not much"), the function can usually be executed properly; Under the Release mode, the EBP stack base pointer is omitted so that the return address error will cause the return address to crash through a global pointer access stack. C strong type features can check most such errors, but if they use forced type conversion, they will not. You can enforce the Add / Oy-Compile option in the Release version to turn off the frame pointer to determine if this class is. Such errors are usually: ● The MFC message response function is written errors. Correct should be an AFX_MSG LRESULT OnMessageown (WPARAM WPARAM, LPARAM LPARAM); an on_message macro contains ambiguous type conversion. One way to prevent this error is to redefine the ON_MESSAGE macro, add the following code to stdafx.h (after #include "afxwin.h"), the function original error compiles error #undef on_Message #define ON_MESSAGE (Message , MEMBERFXN / {Message, 0, 0, 0, AFXSIG_LWL, / (AFX_PMSG) (static_cast
For example, there is a variable that is unused in the function, which is likely to cover a array base, and in the Release version, this variable is likely to be optimized, and the array crosstation will destroy the data used in the stack. Of course, the actual situation will be much more complicated than this. There are errors related to this: ● illegal access, including array offline, pointer error, etc. For example, Void Fn (Void) {INT I; I = 1; Int a [4]; {INT J; J = 1;} a [-1] = 1; // Of course, the error will not be so obvious, such as the subscript is Variable A [4] = 1;} J Although the scope has been used in the array, the space has not been retracted, and I and J will cover the offline. And Release Edition Due to I, J does not have a big role to be optimized, so that the stack is destroyed. 3. _debug and ndebug: When _debug is defined, the assert () function is compiled, while NDebug is not compiled. In addition, there is a series of assertion macros in VC . These include: ANSI C assertion void assert (int expression); C Runtime Lib assertion _ASSERT (booleanExpression); _ASSERTE (booleanExpression); MFC assert ASSERT (booleanExpression); VERIFY (booleanExpression); ASSERT_VALID (pObject); ASSERT_KINDOF (classname, pobject) ATL asserts Atlassert (BooleaneXpression); in addition, the compilation of the Trace () macro is also controlled by _debug. All of these assertions are only compiled in the Debug version, and it is ignored in the release version. The only exception is verify (). In fact, these macros are calling the assert () function, but there are only some debugging code related to the library. If you add any program code in these macros, not just Boolean expression (such as assigning, you can change the variable value of the variable value), then the Release version does not perform these operations, resulting in an error. Beginners are easy to make such mistakes, the method of finding is also very simple, because these macros have been listed above, as long as the VC Find in Files feature is used to find these macros in all files, then check can. In addition, some masters may also join the criteria compilation of #ifdef _debug, but also pay attention to it. By the way, it is worth mentioning the verify () macro, this macro allows you to put the program code in the Boolean expression. This macro is usually used to check the return value of the Windows API. Some people may abuse verify () for this reason, in fact this is dangerous, because verify () violates the idea of asserting, can't completely separate the program code and debug code, and ultimately may bring a lot of trouble. Therefore, experts recommend that this macro is used as much as possible. 4. / GZ option: This option will do these things (1) initialize memory and variables.
