1. Trace macro
When the debug target is selected and the afxtraceenabled variable is set to true, the trace macro is activated. However, in the release version of the program, they are completely forbidden. The following is a typical trace statement:
Int ncount = 9;
Cstring strdesc ("Total ");
Trace ("Count = % d, description = % s/n", ncount, strdesc );
We can see that the trace statement works a bit like the printf statement in C language. The number of Trace macro parameters is variable, so it is very easy to use. If you view the source code of MFC, you cannot find the trace macro, but you can only see trace0, trace1, trace2, and trace3 macros. Their parameters are 0, 1, 2, and 3, respectively.
Ii. Assert macro
If you have designed a function, the function requires a pointer pointing to the document object as a parameter, but you mistakenly call this function with a view pointer. This fake address will cause damage to the visual data. Now, this type of problem can be completely avoided, as long as an Assert test is implemented at the beginning of the function, to detect whether the pointer actually points to a document object. Generally, programmers should routinely use assertion at the beginning of each function. The assert Macro will judge the expression. If an expression is true, the execution will continue. Otherwise, the program will display a message and pause, you can choose to ignore this error and continue or terminate the program or jump to the debug tool. The following example demonstrates how to use an Assert macro to verify a statement.
Void Foo (char P, int size)
{Assert (P! = 0); // check whether the pointer to the buffer is valid.
Assert (size> = 100); // check that the buffer zone contains at least 100 bytes.
// Do the foo Calculation
}
These statements do not generate any code unless the-Debug processor flag is set. Visual c ++ only sets these labels in the debug version, but not in the release version. When-Debug is defined, two assertions generate the following code:
// Assert (P! = 0 );
Do {If (! (P! = 0 )&&
Afxassertfailedline (-file-,-line-) afxdebugbreak ();
} While (0); // assert (size> = 100 );
Do {If (! (Size >=100 )&&
Afxassertfailedline (-file-,-line-) afxdebugbreak ();
} While (0 );
The D0-while loop encapsulates the entire assertion in a separate program block, making the compiler compilation very comfortable. The IF statement calculates the expression value and calls the afxassertfailedline () function when the result is zero. This function will pop up a dialog box with three options "cancel, retry or ignore". When you select "retry", it returns true. A retry will call the afxdebugbreak () function to activate the debugger.
Afxassertfailedline () is an unofficially announced function. Its function is to display a message box. The source code of this function resides in afxasert. cpp. The-file-and-line-statements in the function are processor flags that specify the source file name and the current row number respectively.
3. Verify macro
Because assertion can only play a role in the debug version of the program, the expression cannot contain value assignment statements, add statements (++), or reduce statements (--), because, these statements actually change data. Sometimes you may want to verify a dynamic expression and use a value assignment statement. Then we can use the verify macro to replace assert. For example:
Void Foo (char P, int size)
{Char Q;
Verify (q = P );
Assert (size> = 100 );
// Do the foo calculation}
In debug mode, assert and verify are the same, but in release mode, the verify macro still tests the expression, but assertion does not play any role. In release mode, the assert statement is deleted.
Note that if you mistakenly use a dynamic expression in an Assert statement, the compiler ignores it without warning. In release mode, the expression will be deleted without sound, which will cause program operation errors. Because release programs usually do not contain debugging information, such errors are hard to be found.