VC6.0 compile build release or debug version

You can project->set Active Config and Select the release version. Thereafter, the result of compiling by F5 or F7 is the release version.
--------------------------------------------------------
--------------------------------------------------------
vc6.0 in the setup selected Win32 Release, but point to determine and then open the settings, why did it become Win32 debug?

The Project Settings dialog box shows only the version currently in use and is not intended to be used to set up a compiled version.

If you want to change the version configuration of the current project, you can right-click on the toolbar, check the "Build" option (not "mini build"), and on the toolbar there is a drop-down box that selects the compiled version, which you can choose to "Win32 Debug" or "Win32 release".

Reference:The difference between Debug and release

1. What is the difference between debug and release, and why use release version!
2. How to turn debug into release

The debug version includes debug information, so it is much larger than the release version (possibly hundreds of K to several m). As for whether DLL support is required, it depends on the compilation options you use. In the case of ATL-based, the debug and release versions have the same requirements for DLLs. If you are using an MFC dynamic library with the compile option, you need library support such as MFC42D.DLL, and the release version requires MFC42.DLL support. Release build does not debug the source code, regardless of MFC's diagnostic macros, using the MFC release library, compiled 10 for the speed of the application optimization, and debug build is the reverse, it allows the source code debugging, you can define and use the MFC diagnostic macros, Using the MFC debug Library, the speed is not optimized.


First, Debug and Release The essential difference of the way of compiling

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 secret of Debug and Release lies in a set of compilation options. The options for both are listed below (of course, there are others, such as/FD/FO, but the difference is not important and usually they do not cause the release version error, not discussed here)

Debug version:
/MDD/MLD or/MTD using the Debug Runtime Library (debug version of runtime function library)
/od Turn off the optimization switch
/d "_DEBUG" is equivalent to #define _DEBUG, open the Compile debug code switch (mainly for
Assert function)
/ZI Create the Edit and continue (editing continuation) database so that it has been debugged
If you modify the source code, you do not need to recompile
/GZ can help capture memory errors
/gm to reduce link time by turning on the Minimize heavy link switch

Release version:
/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
Be modified

In fact, 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. In fact, we can even modify these options to get an optimized debug version or a release version with a trace statement.

Ii. under what circumstancesReleaseVersion will go wrong

With the introduction above, let's take a look at each of these options to see how the release version of the error was generated.

1. Runtime Library: Linking which runtime libraries typically affect only the performance of the program. The debug version of the Runtime Library contains debugging information and uses 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 the Debug runtime library strengthens the detection of errors, such as heap memory allocations, sometimes with debug error but Release normal. It should be pointed out that if the Debug error, even if the release is normal, the program must be a Bug, but it is possible that the release version of a run did not show it.

2. Optimizations: 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. There are several main types of errors:

(1) Frame pointer (frame Pointer) ellipsis (FPO): All invocation information (return address, parameters) and automatic variables are placed in the stack during a function call. If the Declaration and implementation of the function is different (parameter, return value, call method), it will produce an error ———— but in the Debug mode, the access of the stack is implemented by the address saved by the EBP register, and if there are no errors (or "not many") in the array, the function will normally execute normally; Release mode, optimizations omit the EBP stack base pointer, so accessing the stack via a global pointer can cause the return address error to be a program crash. The strong-type nature of C + + can check for most of these errors, but it will not work if a forced type conversion is used. You can force the/oy-compilation option in the release version to turn off the frame pointer ellipsis to determine if such an error occurred. This type of error usually has:

MFC message response function writes incorrectly. The right should be
afx_msg LRESULT Onmessageown (WPARAM WPARAM, LPARAM LPARAM);
The On_message macro contains 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"), and the compiler will error 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< LRESULT (afx_msg_call \
CWnd::*) (WPARAM, LPARAM) > (&AMP;MEMBERFXN)},

(2) Volatile 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). Optimizer to improve program performance, some variables are often placed 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 multithreaded, or if you find that the value of a variable does not match your expectations and you are sure that the settings are correct, you are likely to encounter such a problem. This error sometimes manifests itself as a program with the fastest optimization error and minimal optimization. Try adding volatile variables that you think are suspicious.

(3) Variable optimization: The optimizer optimizes variables based on the use of variables. For example, there is an unused variable in the function, and in the Debug version it is possible to mask an array out of bounds, while in release the variable is likely to be tuned, when the array is out of bounds destroying the useful data in the stack. Of course, the actual situation will be much more complicated than this. Errors related to this are:
Illegal access, including array out-of-bounds, pointer errors, etc. 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 a variablehttp://www.cnblogs.com/shanzhizi/
A[4] = 1;
}
J Although the array is out of scope, but its space is not retracted, so I and J will cover the bounds. The release version because I, J does not have a large role may be optimized, 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 asserts void assert (int expression);
C Runtime Lib asserts _assert (booleanexpression);
_asserte (booleanexpression);
MFC asserts assert (booleanexpression);
VERIFY (booleanexpression);
Assert_valid (Pobject);
Assert_kindof (classname, pobject);
ATL asserts 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 they attach some debug code related to the library. If you add any program code to these macros, not just Boolean expressions (such as assignments, function calls that change the value of the variables, etc.), the release version does not perform these operations, causing errors. Beginners can easily make such mistakes, find the method is also very simple, because these macros are listed above, as long as the use of VC + + Find in the files feature in all of the projects found in the project to use these macros in the place to check again. In addition, some experts may also join #ifdef _DEBUG such as conditional compilation, but also pay attention to.
Incidentally, it is worth mentioning that the VERIFY () macro, which allows you to put the program code in a Boolean expression. This macro is typically 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 assertions, does not completely separate the program code from the debug code, and can eventually cause a lot of trouble. Therefore, experts recommend using this macro as sparingly as possible.

4./GZ option: This option will do the following things

(1) Initialize memory and variables. Including initializing all automatic variables with 0xCC, 0xCD (cleared data) initializes the allocated memory in the heap (i.e. dynamically allocated memory, such as New), 0xDD (Dead Data) fills the heap memory that has been freed (for example, delete), 0xFD (Defe NCDE Data) initializes protected memory (the debug version adds protection memory to prevent cross-border access before and after dynamically allocating memory), where the words in parentheses are the mnemonic words suggested by Microsoft. The advantage of this is that these values are large, and as pointers are not possible (and the pointers in the 32-bit system are rarely odd, and in some systems odd pointers produce run-time errors), are rarely encountered as numeric values, and they are easily recognizable, so this is useful for finding release in Debug version Version of the error that you will encounter. It is important to note that many people think that the compiler will initialize the variable with the ".", which is wrong (and this is very bad for finding errors).
(2) When a function is called through a function pointer, the matching of the function call is verified by checking the stack pointer. (Prevent prototype mismatch)
(3) Check the stack pointer before the function returns, confirming that it has not been modified. (Prevent cross-border access and prototype mismatch, with the second item can be roughly simulated frame pointer omitted FPO)

Usually the/GZ option causes the Debug version to go wrong and release version is normal, because uninitialized variables in release release are random, which may cause the pointer to point to a valid address and obscure the illegal access.

In addition, options such as/GM/GF are less likely to cause errors, and their effects are obvious and easier to spot.
--------------------------------------------------------------
Release is a release version, with some optimizations than the debug version, with a file smaller than the debug file
Debug is the debug version, including the program information more
Release method:
Build->batch Build->build is OK.

-----------------------------------------------------

One, "Debug is the debug version, including the program information More"

Add: Only the debug version of the program can set breakpoints, stepping, using Trace/assert and other debugging output statements. The realease does not contain any debugging information, so it is small in size and running fast.

Second, general releaseReleasemethod In addition to Hzh_shat (water), you can also project->set Active Config, select Release version. Thereafter, the result of compiling by F5 or F7 is the release version.

VC6.0 compile build release or debug version