Release Version and debug version, release version debug

Release Version and debug version, release version debug

Programs are generally divided into Debug and Release versions. The Debug version is used for internal debugging, And the Release version is released to users.

What is the difference between Release and Debug?

The Release version is called the Release version, and the Debug version is called the Debug version.

Debug can be executed and tracked in one step, but the generated executable file is relatively large, and the code runs slowly. Release runs fast and has a small executable file, but cannot execute the debugging function under the compiling conditions.

The Release exe file is linked to the Standard mfc dll (Use MFC in a shared or static dll ). These DLL have been configured during Windows installation, so these programs can run on machines without Visual C ++ 6.0 installed. The Debug version exe is linked to the Debug version of the mfc dll file and cannot be run on a machine without Visual C ++ 6.0 installed, because the corresponding DLL is missing, unless you select use static dll when link.

What are the differences between release and debug in VC?

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 secret of Debug and Release lies in a set of compilation options. The options for the two are listed below (of course, there are other options, such as/Fd/Fo, but the difference is not important. Usually they will not cause the Release version error and will not be discussed here)
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 creates the Edit and continue database, so that the source code does not need to be re-compiled if the source code is modified during the debugging process.
/GZ helps capture Memory Errors
/Gm enables the minimize reconnection switch to reduce the link time

Release Version

Parameter description
/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

In fact, 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. In fact, we can even modify these options to get optimized debugging versions or release versions with trace statements.
Under which circumstances will the Release version go wrong?
With the above introduction, let's compare these options one by one to see how Release errors are generated.
1. Runtime Library: Specifies the Runtime function Library to be linked, which usually only affects the performance of the program. The Runtime Library of the debug version contains debugging information and uses some protection mechanisms to help identify errors. Therefore, the performance is inferior to that of the release version. The Runtime Library provided by the compiler is usually stable and does not cause Release errors. However, the Debug Runtime Library enhances error detection, such as heap memory allocation, sometimes there may be Debug errors but Release is normal. It should be pointed out that, if the Debug is wrong, even if the Release is normal, the program must have a Bug, but it may be that a certain run of the Release version is not shown.
2. Optimization: This is the main cause of errors, because the source program is basically translated directly when optimization is disabled, and the compiler will make a series of assumptions after optimization is enabled. There are several types of errors:
1. Frame Pointer (FPO for short): All call information (return address, parameters) and automatic variables are stored in the stack during function calling. If the declaration and implementation of a function are different (parameters, return values, and call methods), an error occurs. However, in the Debug mode, stack access is implemented through the address saved by the EBP register, if no errors such as array out-of-bounds (or "not many" out-of-bounds) occur, the function can normally be executed. In the Release mode, optimization will omit the EBP stack base address pointer, in this way, accessing the stack through a global pointer will cause the program to crash if the returned address is incorrect.
The strong type feature of C ++ can check the majority of such errors, but if forced type conversion is used, it will not work. You can go to the full text in...>

Mfc program. The debug version is normal and the release version is abnormal.

I tested it and RELEASE compiled it. It is OK even if empty content is obtained.
I think it should be caused by too much optimization of the RELEASE version in your project, or other reasons of the program.
Because of the differences between the version and the environment, we recommend that you first test:
Create a similar MFC dialog box project, and use the above Code and RELEASE compilation to check whether there are any problems, compare the optimization parameters of the RELEASE version (adjusted if any). If there is no difference, it should be the issue of interference with other codes of your program. This issue is very troublesome, analysis and Optimization can only be performed when you are familiar with the Code. There are no good suggestions.