Different discussions about debug and release under VC (favorites-reprinted)

Different discussions about debug and release under VC

In the process of using VC to develop software, just when you want to enjoy the excitement, you suddenly find that the release and debug running results are inconsistent or even wrong, and release is not convenient for debugging, it is really a good deal, but it hurts, and the problem always needs to be solved. The following describes some of my experiences to see if it is one of them:

1. variables.
As we all know, the operations performed by debug and release when initializing variables are different. debug assigns each byte to 0xcc (note 1 ), the value assignment of release is similar to random (I think it is allocated directly from the memory and has not been initialized ). This makes it clear that if yourProgramIf a variable in is referenced without initialization, an exception may occur: being used as a control variable will lead to inconsistent process guidance; 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. Therefore, initializing a default value immediately after declaring a variable is the simplest and most effective method. Otherwise, there is no place to find it when the project is too large.CodeErrors may be ignored and not noticed in the debug mode. For example, in the debug mode, most arrays do not go out of bounds and are exposed in the release, this is hard to find: (Please pay more attention to it .)

2. Customize message parameters.
MFC provides us with a good message mechanism and adds custom messages, so I don't need to talk about the benefits. Is there a problem with debug and release? The answer is yes. When declaring the function body of a custom message, you will often see the following statement: afx_msg lresult onmessageown (); In debug mode, there will generally be no problems, however, when you use a message in a multi-thread or process in a release environment, it will lead to errors such as invalid handles. The direct cause of this error is that the message body parameter is not added, that is, it should be written as afx_msg lresult onmessageown (wparam, lparam); (note 2)

3. There is no error in release mode, but an error is reported in debug mode.
In this case, most of them are caused by Incorrect code writing. You can view the source code of MFC and find many assert statements (assertions). This macro is only valid in debug mode, it is clear that the release version does not report errors because it ignores errors rather than no errors. This may pose a major risk because it is easier to debug in debug mode, check your code, and I will not talk about it more.

4. assert, verify, trace .......... Debugging macros
This situation can be easily explained. For example, enter assert under VC and select F12 to jump to the macro-defined place. Here you can find that assert in debug needs to execute afxassertfailedline, the macro definition in release is "# define assert (f) (void) 0 )". Therefore, do not use program variables such as I ++ write statements to debug macro statements. Verify is an exception, "# define verify (f) (void) (f)", that is, execution. The role of verify is not pursued here. If you are interested, you can study it yourself :).

Summary:
Different Problems With Debug and release often occur at the beginning of code writing. 99% is caused by Incorrect code writing, so do not talk about system problems or compiler problems without moving them, the reason for trying to find yourself is the root cause. I used to encounter this situation many times. I started to pay attention to it once and again, and now I have not encountered this problem for a long time in the code I have written. The following are several aspects to avoid. Even if there is no such problem, you should pay attention to it:

1. Pay attention to the initialization of variables, especially pointer variables and array variables (in large cases, another consideration is given ).
2. Standard Writing of custom messages and other declarations
3. comment out the code after debugging a macro.
4. Try to use try-catch (...)
5. Try to use the module to make it clear and convenient for debugging.
Note 1:
AFC:
the debug version is initialized to 0xcc because 0xcc is an int 3 single-step interrupt command under x86, in this way, the program will stop when it encounters 0xcc, which is the same as the JMP 0000 statement in the useless code space during MCU programming.
NOTE 2:
I do not know if you have ever encountered such a situation. I am not sure the specific reason, is it because the wparam + lparam space is allocated according to the default parameters and the memory space of the application is damaged? You can also add them as experts.
submitted by a friend of the following: I have met the parameter stack entry problem when calling a function. Because the message of MFC is written in macros, if the onmessage () function is defined, the compilation can pass, but after one call, the stack pointer is offset. And then...