Differences between debug and release

During the code writing process recently, it is found that debug runs normally, and problems may occur in release, which cannot be solved, but cannot be debugged in release, therefore, you can only gradually locate the problem in printf mode to find that the original array is not initialized, resulting in an exception in subsequent processing. I found some information on the Internet and summarized it as a memo ~

I. Differences between debug and release
Debug is usually called a debug version. It contains debugging information without any optimization, so that programmers can debug programs easily. Release is called a release version. It is often optimized to optimize the code size and running speed, so that users can use it well.

The real difference between debug and release lies in a set of compilation options.
Debug version
Parameter description
/MDD/MLD or/MTD use the debug Runtime Library (the runtime function library of the debug version)
/OD turn off the optimization Switch
/D "_ debug" is equivalent to # DEFINE _ Debug. Enable the compile and debug code switch (mainly for the assert function)
/Zi
Create the edit and continue database, so that you do not need to re-compile the source code if the source code is modified during debugging.

GZ helps capture Memory Errors

Description of release version Parameters
/MD/ml or/MT use the runtime function library of the released version
/O1 or/O2 optimization switch to minimize or minimize the program
/D "ndebug" Disable the Conditional compilation and debugging code switch (that is, do not compile the assert function)
/GF combines repeated strings and puts string constants in read-only memory to prevent Modification

There is no essential limit between debug and release. They are just a set of compilation options, and the compiler only acts according to the predefined options.

Related Experience: From http://dev.csdn.net/article/17/17068.shtm
1. variables.
As we all know, the operations performed by debug and release when initializing variables are different. debug assigns each byte to 0xcc (note 1 ), the value assignment of release is similar to random (I think it is allocated directly from the memory and has not been initialized ). This makes it clear that if a variable in your program is referenced when it is not initialized, it is likely that an exception occurs: using it as a control variable will lead to inconsistent process orientation; using it as an array subscript will cause the program to crash; it is more likely to cause other errors due to inaccuracy of other variables. So it is the easiest and most effective way to initialize a default value for a variable immediately after declaring it. Otherwise, there is no place to find it when the project is too large. Code errors may be ignored and not noticed in the debug mode. For example, in the debug mode, most arrays do not go out of bounds and are exposed in the release, this is hard to find :(
Pay more attention to it.
Oh, it's my problem ~~
2. Customize message parameters.
MFC provides us with a good message mechanism and adds custom messages, so I don't need to talk about the benefits. Is there a problem with debug and release? The answer is yes. When declaring the function body of a custom message, you will often see the following statement: afx_msg lresult onmessageown (); In debug mode, there will generally be no problems, however, when you use a message in a multi-thread or process in a release environment, it will lead to errors such as invalid handles. The direct cause of this error is that the message body parameter is not added, that is, it should be written as afx_msg lresult onmessageown (wparam, lparam
Lparam); (note 2)
3. There is no error in release mode, but an error is reported in debug mode.
In this case, most of them are caused by Incorrect code writing. You can view the source code of MFC and find many assert statements (assertions). This macro is only valid in debug mode, it is clear that the release version does not report errors because it ignores errors rather than no errors. This may pose a major risk because it is easier to debug in debug mode, check your code, and I will not talk about it more.

4. assert, verify, trace ...... debug macro
This situation can be easily explained. For example, enter assert under VC and select F12 to jump to the macro-defined place. Here you can find that assert in debug needs to execute afxassertfailedline, the macro definition in release is "# define assert (f) (void) 0 )". Therefore, do not use program variables such as I ++ write statements to debug macro statements. Verify is an exception, "# define verify (f) (void) (f)", that is, execution, the role is not pursued here, interested in your own research :).

Summary:
Different Problems With Debug and release often occur at the beginning of code writing. 99% is caused by Incorrect code writing, so do not talk about system problems or compiler problems without moving them, the reason for trying to find yourself is the root cause. I used to encounter this situation many times. I started to pay attention to it once and again, and now I have not encountered this problem for a long time in the code I have written. The following are several aspects to avoid. Even if there is no such problem, you should pay attention to it:

1. Pay attention to the initialization of variables, especially pointer variables, array variables (in large cases, another consideration ).
2. Standard Writing of custom messages and other declarations
3. It is best to comment out the code after debugging a macro.
4. Try to use try-catch (...)
5. Try to use the module to make it clear and easy to debug.
Note 1:
The debug version is initialized to 0xcc because 0xcc is an int 3 single-step interrupt command in x86, so that the program will stop when it encounters 0xcc, this and the microcontroller programming generally useless code space filled in JMP 0000 statements is the same as the reference information: http://it.china-b.com/ejks/c/20090521/5088_1.htmlhttp://home.putclub.com/space.php? Uid = 738315 & Do = Blog & id = 39809