Differences between debug and release versions in VC

There is no essential difference between debug and release. They are just a set of two sets of compilation options provided by VC, And the compiler only acts according to the predefined options. If we want to, we can totally turn the actions of debug and release upside down. Of course, you can also provide other modes, such as defining a set of compilation options and naming them as my_abc. Traditionally, we prefer to use the name defined by VC.
The debug version includes debugging information, so it is much larger than the release version (which may be several hundred kb to several Mb ). As to whether DLL support is required, we mainly look at the compilation options you use. If it is based on ATL, debug and release have similar requirements on DLL. If you use the dynamic MFC Library as the compilation option, you need to support mfc42d. dll and other libraries. The release version requires the support of mfc42.dll. Release does not debug the source code. It does not take into account the MFC diagnostic macro. It uses the MFC release library to optimize the application speed during compilation, while debug is the opposite, it allows debugging of source code, defines and uses the diagnostic macro of MFC, and uses the debug library of MFC, which does not optimize the speed.
Since debug and release are only different compilation options, why should we differentiate debug and release versions?
Debug and release, in my opinion, are primarily differentiated based on their specific targets. Debug is usually called a debugging version. With the combination of a series of compilation options, the compilation results usually contain debugging information without any optimization, providing developers with powerful application debugging capabilities. Release is usually called a release version and is intended for users. Generally, users are not allowed to debug the released version. Therefore, the debugging information is not saved. At the same time, it is often optimized to minimize the code and optimize the speed. It facilitates users' usage.

The following is only a comparison of the default debug and release options. For details about the compilation options, see the description of msdn.
We compare the default debug and release options to filter out the same settings. The main differences are as follows:
Compilation options:/OD/D "_ debug"/GM/rtc1/MDD/FO "debug" "/Zi
Link options:/out: "D:" myproject "logging" debug "optiontest. dll"/Incremental
Release settings:
Compilation options:/O2/Gl/D "ndebug"/FD/MD/FO "release"/Zi
Link options:/out: "D:" myproject "logging" release "optiontest. dll"/Incremental: No

Debug version:

/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 creates the edit and continue database. If the source code is modified during debugging, you do not need to re-compile the database.
/GZ helps capture Memory Errors
/GM enables the minimize reconnection switch to reduce the link time

Release Version:
/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 repeat strings and puts string constants in read-only memory to prevent modification.

MDD and MD
First, the debug version uses the debug version's Runtime Library (/MDD option), and The relase version uses the released version's Runtime Library (vcrt. dll ). The main difference is the performance impact during running. The Runtime Library of the debug version contains debugging information and uses some protection mechanisms to help identify errors. Therefore, its performance is inferior to that of the released version. The Runtime Library provided by the compiler is very stable and will not cause release version errors. The debug version's Runtime Library enhances error detection, such as heap memory allocation check. Instead, it reports errors, it should be noted that if debug has errors and the release version is normal, the program must have bugs, but we have not found them yet.
Zi and Zi
Second, the/Zi option and/Zi option. By using the/Zi option, you can modify the code during the debugging process without re-compiling. This is a good helper for debugging, but if we use the release version, this will become unavailable.

OD and O2
/O2 and/OD options: OD is used to disable Compiler Optimization and is widely used in debug versions. The O2 option is the fastest way to create code, which is of course the best choice for the release version.

Rtcx
The/rtcx option allows the compiler to insert dynamic detection code to help you detect errors in the program. For example, it initializes a local variable to a non-zero value. Including using 0xcc to initialize all automatic variables, 0xcd to initialize memory allocated in the heap (I .e. new memory), and 0xdd to fill the released memory (I .e. delete memory ), 0xfd initializes the protected memory (debug adds the protected memory before and after the dynamically allocated memory to prevent cross-border access ). The advantage of doing so is that these values are very large and generally cannot be used as pointers, exams, and big tips are rarely used as values, and these values are easy to recognize, therefore, it is helpful to find the release version errors. In addition, when a function is called through the function pointer, the matching of the function call is verified by checking the stack pointer (to prevent the prototype mismatch ). When the/rtcx option is used, debugging version errors may occur, while the release version is normal. Because uninitialized variables in the release version are random, it is likely that the pointer points to a valid but incorrect address, this masks errors. This compilation option can only be used under the/OD option.

GM, incremental or no
The GM in the compilation option and the incremental in the Link option are only for one purpose, speeding up compilation. We often encounter this problem. Only one header file is modified, but all dynamic libraries are recompiled. These two options are used to solve the problem. If the/GM switch is enabled, the compiler stores the dependency between the source file and the class definition in the. IDB file of the project. In the subsequent compilation process, use the information in the. IDB file to determine whether to compile a source file, even if the source file already contains the modified. h file.
The incremental switch is enabled by default. The executable files generated by using incremental links or the dynamic link library will be larger than the programs generated by non-incremental links because of code and data filling. In addition, the incremental link file also contains a jump to the trunk to relocate the processing function to the new address.
Msdn clearly states that to ensure that the final release version does not contain a fill or trunk, please do not add a link program.

/GZ option: do the following:
1. Initial memory and variables. Including using 0xcc to initialize all automatic variables, 0xcd (cleared data) to initialize memory allocated in the heap (that is, dynamically allocated memory, such as new), 0xdd (dead data) fill in the released heap memory (for example, delete), 0xfd (defencde data) initialize protected memory (the debug version adds protected internal memory before and after dynamic memory allocation to prevent cross-border access). The words in brackets are the mnemonic words recommended by Microsoft. The advantage of doing so is that these values are very large and cannot be used as pointers (and in 32-bit systems, pointers are rarely odd values, in some systems, odd-number pointers produce runtime errors), which are rarely used as numerical values, and these values are easy to recognize, therefore, this is very helpful for the release of release in the debug version. Note that many people think that the compiler will use 0 to initialize the variable, which is wrong (and this is not conducive to finding the error ).
2. When a function is called through the function pointer, the matching of the function call is verified by checking the stack pointer. (Prevent original form mismatch)
3. Check the stack pointer before the function returns, and confirm that it has not been modified. (Avoid out-of-bounds access and original form mismatch. When combined with the second item, you can roughly simulate frame pointer omitting FPO)

Usually, the/GZ option causes errors in the debug version and the release version is normal, because uninitialized variables in the release version are random, this may cause the pointer to point to a valid address and mask illegal access.

_ Debug and ndebug
This is the most important option. The two are pre-processor definitions of the compiler. By default, _ debug is used for the debug version, while ndebug is used for the release version. They can be said to be important. Because assert series assertions only take effect under _ Debug!

Differences between debug and release versions in VC