Abstract
Recently, Visual Studio has been widely used. Although it is a little slow, it still feels good to be familiar with it, especially the automatic formatting code in 2013, this is a great help for my obsessive-compulsive disorder patients with neat code.
However, today, this pitfall has been detected for almost a day.
Environment: win8.1 64bit Visual Studio 2013 qt5.3
Differences between debug and release versions
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.
Reason for different running results
The operations performed by debug and release when initializing variables are different. debug assigns each byte to 0xcc, and the value assignment of release is similar to random. If a variable in your program is referenced without being initialized, an exception is likely to occur: being used as a control variable will lead to inconsistent process orientation; being used as an array subscript will cause the program to crash; it is more likely that other variables are inaccurate and other errors are caused. So it is the easiest and most effective way to initialize a default value for a variable immediately after declaring it. Otherwise, there is no place to find it when the project is too large. Code errors may be ignored and not noticed in debug mode. In the debug mode, most arrays do not go out of bounds and are exposed in the release, which is difficult to find.
Problems I encountered
One problem I encountered here is to apply for a memory segment to store the pixel values of images in the memory, and store them in the argb format, that is, the alpha channel is 1bit, the red channel is 1bit, and the green channel is 1bit, the blue channel is 1 bit, and each pixel is represented by four elements.
int length = uiCols * uiRows * bytesPerPixel;unsigned char* m_arpBGRABuffers = new unsigned char[length];//Save RGB value to buffer
Finally, it is stored in qimage for display.
In debug mode, the display is correct,A little grayIn release mode.
Finally, locate the memory application location and print out the memory value. It is found that all arrays in debug mode are assigned 205 values, and all arrays in release mode are assigned 0 values.
The question is, why is it 205 !?
Hurry up with Visual Studio 205.
It was found that a buddy encountered a similar problem on cplusplus.
struct COLOR{ unsigned char R; unsigned char G; unsigned char B;};int main(){ COLOR * color; color = new COLOR[5]; cout << (int)color[3].G //Default value of a color part....(right?) return 0;}
The above, for some reason, returns a value of 205.
205 !? Why !?! Every R, G, and B of every color in the array is set to 205 !!!
Please give me an explanation...
He needs an explanation.
It is peculiarity of the Microsoft product (s ):
If you declare a variable say for example:
Int A then if it not initialised and you run the program then in the debugger it will show a value as follows:
Char type will be 0xcc (decimal 204)
Short will be 0 xcccc
Int will be 0 xcccccccc
And so on.
If you create a variable/struct using new then if you run the program but have not initialised the variable/structure values
Then you will see in the debugger:
Char type will be 0xcd (decimal 205 )******
Short will be 0 xcdcd
Int will be 0 xcdcdcdcd
And so on.
An unitialised pointer will show as 0 xcccccccc
I believe it really does put those values in-because if you try to cout an uninitialised variable and ignore the 'unitialised variable error dialog box'
Then you really will see those values on the screen.
Now I understand...
The reason why the release mode is not displayed is that the alpha channel is assigned 0, and the debug mode is a bit grayed out because the alpha channel is assigned 205 (completely opaque is 255 ).
The initial values are assigned to all solutions:
int length = uiCols * uiRows * bytesPerPixel;char * m_arpBGRABuffers = new unsigned char[length];//Set ALL chinnal to 255for (int i = 0; i < length; i++){m_arpBGRABuffers[iCamera][i] = 255;}
Now the whole world is clear. Comparison:
Gray images in debug mode
Set Alpha to 255 in release Mode
Summary
All class members assign the initial values in the constructor. Do not trust the behaviors of dependent compilers.
Apply for memory variables dynamically. Assign the initial value immediately after applying for memory.
The compiling results of debug and realse in Visual Studio are different.