The Debug version includes debugging information, so much more than the release version (possibly large hundred k- to numbers). 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. Essential difference between Debug and Release compilation
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)
Debug version:
/ MDD / MLD or / MTD uses Debug Runtime Library (debug version runtime "
/ OD close optimization switch
/ D "_debug" is equivalent to #define _debug, open the compiled debug code switch (mainly for
askERT function)
/ Zi Create Edit and Continue (editing) database, which is debugging
If you modify the source code, you need to recompile.
/ GZ can help capture memory errors
/ GM opens minimized weight link switch, reduce link time
RELEASE version:
/ Md / ml or / mt uses the release version of the runtime function library
/ O1 or / O2 optimize the switch to minimize the program or the fastest
/ D "ndebug" Close condition compiles debug code switch (ie, does not compile Assert function)
/ GF combined repetitive strings and put the string constants in read-only memory to prevent
modified
In fact, Debug and Release have no essential boundaries, they are just a set of compile options, and the compiler is just a scheduled option 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 is wrong
With the above introduction, let's take a look at these options to see how the Release version is generated.
1. Runtime Library: Which runtime library is usually only impact on 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 omission (referred to as FPO): During 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
AFX_MSG LRESULT OnMESSAGEOWN (WPARAM WPARAM, LPARAM LPARAM);
ON_MESSAGE macro contains forced 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 is compiled when the function is wrong.
#undef on_Message
#define on_Message (Message, MemberfxN) /
{Message, 0, 0, 0, AFXSIG_LWL, /
(AFX_PMSG) (AFX_PMSGW) (static_cast CWnd :: *) (WPARAM, LPARAM)> (& MemberfxN)} (2) Volatile type variable: Volatile tells the compiler that the variable may be modified in an unknown manner outside the program (such as system, other processes, and threads). Optimization procedures in order to increase program performance, some variables are often placed in registers (similar to the register keyword), while other processes can only modify the memory where the variable is located, and the value in the register has not changed. If your program is multi-thread, or you find that the value of a variable does not match the expected, you are confident that it is set, it is likely to encounter such problems. This error sometimes manifests the program to optimize the normal optimization in the fastest optimization. Try the VOLATILE that you think is suspicious. (3) Variable Optimization: The optimization procedure optimizes variables according to the use of variables. 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. E.g 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 a variable. a [4] = 1; } J Although the scope has been used in the array of crosses, the space has not been retracted, so 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 . This includes: ANSI C asserts Void Assert (int Expression); C Runtime LIB assertion_assert (booleaneXpression); _Asserte (booleaneXpression); MFC asserts Assert (BooleaneXpression); Verify (BooleaneXpression); Ask_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 the memory and variables. Including all automatic variables, 0xCD (ie, dynamically assigned memory, such as new), 0xDD (DEAD DATA), 0xFD (DEFENCDE), 0xCD (DEFENCDE), 0xFD (DEFENCDE) DATA) Initializing the protected memory (DEBUG version is added to prevent memory before and after dynamic allocation to prevent offshore access), where the words in the parentheses are a help letter proposed by Microsoft. The benefits of doing this are that these values are very large, and it is impossible as a pointer (and the pointer in the 32-bit system is rarely odd, and the odd pointer in some systems will generate runtime errors), as a few more It is also easy to identify, so this is also very beneficial to find the error that Release version will encounter in the Debug version. It is important to note that many people think that the compiler will use 0 to initialize the variable, which is wrong (and this is very disadvantage). (2) When the function is called, the function call is verified by checking the stack pointer. (Preventing the original formation) (3) The function returns the front inspection stack pointer to confirm that it is not modified. (Prevent off -ral access and original formation, with the second item, can generally simulate the frame pointer omitted FPO) The usual / gz option will cause the Debug version error and the release version is normal, because the variables that are not initialized in the Release version are random, which may make the pointer to cover a valid address to mask illegal access. In addition, / GM / GF and other options have less errors, and their effect is obvious, it is easier to find.
