What's the difference between Debug and release?

I'm working on it recently because SVN's server is on my computer. The system is built on my computer first. And then release it for everyone to use. Which is why I found this problem in the process.

Presumably, I don't know when I'm going to put my mode of operation into release mode. Then I upload it to the server and there will be an error when others download it. Although the problem of the emergence of the solution soon, but the problem is still need to make a good summary.

first, want to solve this problem to understand is the difference between debug and release.

This network said a lot of I also roughly say:

Debug is often referred to as the debug version, which contains debugging information and is not optimized to allow programmers to debug programs. Release is known as a publish version, it is often a variety of optimizations, so that the code size and speed of the program is optimal, so that users are very good to use.

The real difference between debug and release is a set of compilation options ... The following is a list of options for each

Debug version

Parameters	Meaning
/MDD/MLD or/MTD	Using the Debug Runtime Library (debug version of Run-time function libraries)
/od	Turn off the tuning switch
/d "_DEBUG"	Equivalent to #define _DEBUG, open the Compile debug code switch (mainly for the Assert function)
/zi	Create an Edit and continue (edit continue) database so that if you modify the source code without recompiling during debugging
GZ	Can help capture memory errors
/gm	Turn on minimizing the link switch to reduce link time

Release version:

Parameters	Meaning
/MD/ML or/MT	Run-time function library with release version
/o1 or/o2	Optimize the switch to make the program minimum or fastest
/d "Ndebug"	Close conditional compile debug code switch (that is, do not compile assert function)
/gf	Merges duplicate strings and places string constants in read-only memory to prevent modification

In fact, there is no intrinsic boundary between Debug and release, they are just a collection of compilation options, and the compiler simply acts on the predefined options. In fact, we can even modify these options to get optimized debug versions or release versions with trace statements.

So where are the two things that are compiled? Of course, these two things are not just referring to which. dll file, but a set of. dll collections that are generated in this mode. Speaking of which, I think we all understand. is actually the debug and release two folders under the Bin folder.

Then we analyze the reason for the error: I did not upload my Bin folder when I uploaded the system, as I said in my previous blog (connection address http://blog.csdn.net/hy6688_/article/details/9500149). Of course, when other members download the "Cannot find So-and-so assembly," because they have not yet generated.

Of course, this problem is to prevent the occurrence of similar problems in the future, summed up the relevant issues:

second, in which case release version will be wrong

With the above description, let's take a look at these options individually to see how release errors are generated

1. Runtime Library:

Link which run-time function library usually only has an impact on the performance of the program. The debug version of the Runtime Library contains debugging information and has some protection mechanisms to help identify errors, so performance is not as good as the release version. The Runtime Library provided by the compiler is usually stable and does not cause release errors; but because the debug Runtime Library has tightened detection of bugs, such as heap memory allocations, there are sometimes debug errors, but Re Lease the normal phenomenon. It should be noted that, if Debug error, even if the release is normal, the program must be a Bug, but may be released version of a run did not show it.

2. Optimization:

This is the main cause of the error, because the source program is basically translated directly when the optimization is turned off, and the compiler makes a series of assumptions when the optimization is turned on. These types of errors are mainly as follows:

(1) Frame pointer (pointer) omitted (abbreviated FPO):

All call information (return address, parameters), and automatic variables are placed on the stack during the function call.  If the declaration of the function is different from the implementation (parameter, returns the value, the invocation method), will produce the error ———— but in the Debug way, the stack's access is realized through the EBP register save address, if does not have the array to cross the line and so on error (or crosses the line "not many"), the function usually can execute normally; release mode, optimizations omit the EBP stack base address pointer, so accessing the stack via a global pointer causes the return address error to be a program crash. The strongly typed nature of C + + can check out most of these errors, but not if you use coercion type conversions. You can force the/oy-compilation option in release version to turn off frame pointer ellipsis to determine whether this type of error occurs. This type of error is usually:

MFC Message response function write error. The correct should be

afx_msg lresult Onmessageown (WPARAM WPARAM, LPARAM LPARAM);

On_message macros contain coercion type conversions. One way to prevent this error is to redefine the On_message macro and add the following code to the stdafx.h (after #include "AFXWIN.h"), the compiler will complain when the function is in the wrong shape

#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 type variable:

Volatile tells the compiler that the variable may be modified in an unknown way outside of the program (such as systems, other processes, and threads). In order to improve program performance, the optimizer often places variables in registers (similar to the Register keyword), while other processes can only modify the memory in which the variable resides, while the value in the register does not change. If your program is multi-threaded, or you find that the value of a variable does not match what you expected and you are sure you have set it correctly, you are likely to experience this problem. This type of error can sometimes be manifested as a program with the fastest optimization error and minimal optimization normal. Try to add volatile to the variable you think is suspicious.

(3) variable optimization:

The optimizer optimizes variables based on the use of variables. For example, there is an unused variable in the function that in the Debug version might mask an array out of bounds, and in release, the variable is likely to be tuned, and the array's bounds will break the useful data in the stack. Of course, the actual situation would be much more complicated than that. The errors associated with this are:

Illegal access, including array bounds, pointer errors, and so on. For example

VOID fn (void)
{
	int i;  
	i = 1;  
int a[4];  
{
	int J;  
	j = 1;
}  
A[-1] = 1;//Of course the error is not so obvious, for example subscript is variable
a[4] = 1;
}

Although the scope of the array is out of bounds, but the space is not retracted, I and J will cover up the bounds. and release version because I, J does not have a great effect may be optimized out, so that the stack is destroyed.

3. _DEBUG and Ndebug:

When _DEBUG is defined, the Assert () function is compiled, and Ndebug is not compiled. In addition, VC + + also has a series of assertion macros. This includes:

ANSI C assertion void assert (int expression);

C Runtime Lib Assertion _assert (booleanexpression);

_asserte (booleanexpression);

MFC assertion assert (booleanexpression);

VERIFY (booleanexpression);

Assert_valid (Pobject);

Assert_kindof (classname, pobject);

ATL Assertion Atlassert (booleanexpression);

In addition, the compilation of TRACE () macros is also controlled by _DEBUG.

         All of these assertions are compiled only in the  debug version and are ignored in the  release   version. The only exception is  verify ()  . In fact, these macros all call the  assert ()   function, except that some debugging code related to the library is attached. If you add any program code to these macros, not just Boolean expressions (such as assignment, function calls   etc. that can change the value of a variable), then  release   does not perform these actions, causing an error. Beginners can easily make such errors, and the search method is simple, because these macros are listed above, as long as the use of  vc++