The difference between Debug and release

VC under Debug and release differences

Recently wrote the code process, found that the Debug run normal, release under the problem, the solution, and the release can not be debugged, and can only be used in the printf way to gradually locate the problem, only to find that the original is given an array is not initialized, Causes the exception to be handled later. Find some information on the Internet, in this list of summary, as a memo ~
The difference between Debug and Release
Debug is often called a debug version, it contains debugging information, and does not make any optimizations to facilitate the programmer to debug the program. Release, known as the release version, is often optimized to make the program optimal in terms of code size and speed, so users can use it well.
The real difference between Debug and Release is a set of compilation options.
Debug version
Parameter meaning
/MDD/MLD or/MTD using the Debug Runtime Library (debug version of runtime function library)
/od Turn off the optimization switch
/d "_DEBUG" equivalent to #define _DEBUG, open the Compile debug code switch (mainly for the Assert function)
/zi
Create the edit and continue database so that if you modify the source code during debugging, you do not need to recompile
GZ can help capture memory errors

Release version parameter meaning
/MD/ML or/MT using a published version of the runtime function library
/O1 or/o2 optimized switch for minimum or fastest program
/d "Ndebug" Turn off conditional compilation debug code switch (that is, do not compile the Assert function)
/GF merges duplicate strings and puts string constants into read-only memory to prevent modification

Debug and Release do not have an essential boundary, they are just a set of compilation options, and the compiler simply acts according to the intended options.
Related experience: Transfer from http://dev.csdn.net/article/17/17068.shtm
1. Variables.
As you know, Debug and release do different things when initializing variables, debug is to assign each byte bit to 0XCC (note 1), and the assignment of release is approximate to random (I want to be allocated directly from memory, not initialized). This makes it clear that if a variable in your program is referenced without being initialized, there is a good chance of an exception: the use of a control variable will result in a process-oriented inconsistency, and being used as an array subscript will cause the program to crash, and more likely to cause inaccuracies in other variables to cause other errors. Therefore, it is the simplest and most effective way to initialize a default value immediately after declaring a variable, otherwise you will find no place to find it. Code errors in the debug mode may be ignored without being detected, such as the debug mode of the array out of bounds also most can not error, in the release is exposed, this find is more difficult: ( Let's just take care of yourself.
Oh, that's the problem I made ~ ~
2. Customize message parameters for messages.
MFC has provided us with a good message mechanism, but also added a custom message, the benefits I will not have to say more. Is there a problem with Debug and release? The answer is yes. When you declare a function body of a custom message, you will often see such a notation: afx_msg LRESULT onmessageown (); In the case of debug, there is generally no problem, and when you are under release and a multi-thread or process is using message passing, an error such as an invalid handle is caused. The direct cause of this error is that the parameters of the message body are not added, which should be written as: afx_msg LRESULT onmessageown (WPARAM WPARAM, LPARAM LPARAM); (Note 2)
3. No error in release mode, but error in debug mode.
In this case, most of the code is due to write incorrectly, view the source of MFC, you can find a lot of assert statements (assertions), this macro is only valid in debug mode, then it is clear that the release version of the error is ignored errors and not without errors, This may be a big hidden trouble, because it is debug mode, more convenient debugging, good check their own code, and then not much to say.
4. ASSERT, VERIFY, TRACE ..... Debug macros
The situation is easy to explain. For example: Please enter assert under VC and check Press F12 to jump to macro definition where you will be able to find that the assert in debug executes Afxassertfailedline, while the macro definition under release is "#define ASSERT (f) (void) 0) ". So note that the statements in these debug macros do not use program-related variables such as i++ write operations. VERIFY is an exception, "#define VERIFY (f) ((f))", that is, enforcement, where the role is not much pursued, and interested to study:).

Summarize:
Debug and release different problems often occur at the beginning of writing code, 99% is due to your code writing errors, so do not always say system problems or compiler problems, and strive to find their own reasons is fundamental. I've been through this before and I've been through a lot of lessons, and now I've written code that I haven't had in a long time. Here are a few aspects to avoid, even if you do not have this problem should be noted:
1. Notice the initialization of the variable, especially the pointer variable, and the initialization of the array variable (in large cases another consideration).
2. Standard notation for custom messages and other claims
3. It is best to comment out when using a debug macro
4. Try to use Try-catch (...)
5. Use the module as much as possible, not only to express clearly and convenient debugging.
Note 1:
Debug version initialized to 0XCC is because 0XCC in x86 is an int 3 single-step interrupt instruction, so that the program if run to meet 0XCC will stop, this and microcontroller programming generally will not be useless code space in the JMP 0000 statement is the same as posted in: Computer Secondary examination _ Exam Big " Zebian: Drfcy Error Correction "
[VC] Debug and RELEASE2007 August 26 Sunday pm 04:33 I. Memory allocation issue
1. The variable is not initialized. The following program runs very well in debug.
Thing * Search (thing * something)
BOOL found;
for (int i = 0; i < whatever. GetSize (); i++)
{
if (Whatever[i]->field = = Something->field)
{/* found it */
Found = TRUE;
Break
}/* Found it */
}
if (found)
return whatever[i];
Else
return NULL;
But not in release, because in debug, the variable is automatically initialized to Found=false, and in the release version will not. So initialize the variable, class, or struct as much as possible.
2. Data overflow Issues
such as: Char buffer[10];
int counter;
lstrcpy (buffer, "Abcdefghik");
In debug version, buffer null covers the counter high, but unless counter>16m, there is no problem. However, in release version, counter may be placed in the register, so that null overwrites the space under buffer, possibly the return address of the function, which causes access ERROR.
3. The mode of memory allocation for debug and release editions is different. If you are applying ele to 6*sizeof (DWORD) =24bytes in the debug version, you are actually assigned 32bytes (the debug version is allocated in 32bytes), and in the release version, Assigned to you is 24bytes (release version in 8bytes units), so in the debug version if you write Ele[6], there may be no problem, and in release version, there is access violate.
II. Assert and verify
1. Assert is not compiled in release version.
The Assert macro is defined like this
#ifdef _DEBUG
#define ASSERT (x) if ((x) = = 0) report_assert_failure ()
#else
#define ASSERT (x)
#endif
It's actually a little more complicated, but irrelevant. If you add in these statements the code that you must have in your program
Like what
ASSERT (pnewobj = new CMyClass);
Pnewobj->myfunction ();
Pnewobj in release releases are not allocated to space at this time
Therefore, when executing to the next statement, the program will report that the program has performed an illegal operation error. This can be used verify:
#ifdef _DEBUG
#define VERIFY (x) if ((x) = = 0) report_assert_failure ()
#else
#define VERIFY (x) (x)
#endif
In this case, the code can be executed in the release version.
Iii. parameter issues:
The handler function for the custom message must be defined as follows:
afx_msg LRESULT onmymessage (WPARAM, LPARAM);
The return value must be an HRESULT, or debug will be over, and the release error
Iv. Memory allocation
Ensure consistency in data creation and cleanup: If a DLL provides a function to create data, the DLL should also provide a function to destroy the data. The creation and cleanup of data should be on the same level.
V. DLL disaster
People will mix different versions of DLLs resulting from the inconsistency of the image called "Dynamic Connection Library Hell" (DLL Hell), even Microsoft itself said so Http://msdn.microsoft.com/library/techart/dlldanger1.htm )。
If your program uses your own DLL, please note that:
1. You cannot mix debug and release versions of DLLs together. Debug is the debug version, release version is release version.
The solution is to place the debug and release programs in the Debug and release directories of the main program, respectively.
2. Never assume that a static connection to the library will solve the problem, which will only make the situation worse.
Vi. debugging in the release board:
1. Change the Assert () to VERIFY (). Find the code that is defined in "#ifdef _DEBUG", and if you need it in the release version, move them out of the definition. Find Trace (...) Code, because the code is not compiled in release. Please check carefully if the code you need in release is not cheap.
2. There are differences in the initialization of variables, in different systems, or between debug/release versions, so initialize the variables.
3. Do you already have a warning at compile time? Set the warning level to 3 or 4, and then ensure that no warnings appear at compile time.
VII. Change the optimization option under Project Settings "C++/C" to Disbale (Debug). Compiler optimizations can cause many unexpected errors, please refer to http://www.pgh.net/~newcomer/debug_release.htm
1. In addition to the release version of the software can also be debugged, please make the following changes:
Under Project Settings, set the category to "General" under the "C++/C" item and set the "Debug Info" to "program Database".
Under the Link item, select the Generate Debug Info check box.
"Rebuild All"
Some of the limitations of this approach are:
Cannot get the value of a variable in an MFC DLL.
All DLL works that are used by the software must be modified.
Other:
A technical document in MS Bug:ms shows that the "Maximize speed" optimization option for DLLs in VC5 is not fully supported, so this will cause memory errors and cause the program to crash.
2. http://www.sysinternals.com/has a program DebugView to capture the output of the OutputDebugString, after it has been run (estimated to be self-set to system Debugger) You can see the output of the outputdebugstring of all programs. After that, you can run your program out of the VC and watch the debugging information.
3. There is a static code called Gimpel Lint Check tool, it is said to be more useful http://www.gimpel.com/but to the $.

The difference between Debug and release