Different discussions about debug and release under VC

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 a variable in your program is referenced when it is not initialized, it is likely that an exception occurs: using it as a control variable will lead to inconsistent process orientation; using it as an array subscript will cause the program to crash; it is more likely to cause other errors due to inaccuracy of other variables. 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 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, array variables (in large cases, another consideration ).
2. Standard Writing of custom messages and other declarations
3. It is best to 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 easy to debug.

 

 

Remember to initialize all the variables that need to be used !!!