文章来源：
http://www.codeguru.com/
文章作者：cilu
Q: What is an assertion?
A: An assertion statement specifies a condition that you expect to hold true at some particular point in your program. If that condition does not hold true, the assertion fails, execution of your program is interrupted, and the Assertion Failed dialog box appears.
Q: What kind of asserts does Visual C++ support?
A: Visual C++ supports assertion statements based on the following constructs:
MFC assertions for MFC program
ATLASSERT for programs that use ATL
CRT assertions for programs that use the C run-time library
ANSI assert function for other C/C++ programs
Q: What good are assertions for:
A: You can use assertions to:
Catch logic errors
Check results of an operation
Test error conditions that should have been handled
Q: What is MFC's ASSERT?
A: A macro definition that allows you to evaluate an expression. If the expression is evaluated to 0, the macro prints a diagnostic message and aborts the program. If the condition is nonzero, it does nothing. The diagnostic message has the form
Code:
assertion failed in file _filename_ in line _linenum_
where _filename_ is the name of the source file, and _linenum_ is the line number of the assertion that failed in the source file. In an MFC ISAPI application, an assertion in debug mode will bring up a modal dialog box; this will interrupt or hang the execution.
Q: Are there another MFC assertion macros?
A: Yes, you can also use one of these:
ASSERT_KINDOF(classname, pobject) - This macro asserts that the object pointed to is an object of the specified class, or is an object of a class derived from the specified class.
Code:
ASSERT_KINDOF(CMyDocument, pDocument)
if identical with
Code:
ASSERT(pobject->IsKindOf(RUNTIME_CLASS(classname)));ASSERT_VALID(pobject) - Used to test an assumptions about the validity of an object's internal state. The parameter must be an object of a class derived from CObject that has an overriding version of the AssertValid member function. ASSERT_VALID validates the pointer, checks against NULL, and calls the object's own AssertValid member functions.
Q: What about ATLASSERT?
A: The ATLASSERT macro performs the same functionality as the _ASSERTE macro found in the C run-time library.
Q: What are the CRT assertion macros?
A: The CRTDBG.H header file defines the _ASSERT and _ASSERTE macros for assertion checking. The result of these macros are:
_ASSERT: If the specified expression evaluates to FALSE, the file name and line number of the _ASSERT
_ASSERTE: Same as _ASSERT, plus a string representation of the expression that was asserted
Q: How do I chose between _ASSERT and _ASSERTE?
A: _ASSERTE is more powerful because it reports the asserted expression that turned out to be FALSE. This may be enough to identify the problem without referring to the source code. However, the Debug version of your application will contain a string constant for each expression asserted using _ASSERTE. If you use many _ASSERTE macros, these string expressions take up a significant amount of memory. If that proves to be a problem, use _ASSERT to save memory.
Q: And about the ANSI assertion funtion?
A: assert() evaluates an expression and, when the result is false, prints a diagnostic message and aborts the program.
The ANSI assert macro is typically used to identify logic errors during program development by implementing the expression argument to evaluate to false only when the program is operating incorrectly. After debugging is complete, assertion checking can be turned off without modifying the source file by defining the identifier NDEBUG. NDEBUG can be defined with a /D command-line option or with a #define directive. If NDEBUG is defined with #define, the directive must appear before Assert.h is included.
assert prints a diagnostic message when expression evaluates to false (0) and calls abort to terminate program execution. No action is taken if expression is true (nonzero). The diagnostic message includes the failed expression and the name of the source file and line number where the assertion failed.
Q: Can I see an example of assert()?
A: Here is a simple example and the output. Consider the file is called test.cpp:
Code:
#include "assert.h"
int main()
{
int* array = NULL;
assert(array != NULL); // this should fail
return 0;
}
output is:
Code:
Assertion failed: array != NULL, file test.cpp, line 7
abnormal program termination
Q: Do asserts work in release version also?
A: No, only in debug version. In the release version of MFC, ASSERT does not evaluate the expression and thus will not interrupt the program. If the expression must be evaluated regardless of environment, use the 'VERIFY' macro in place of 'ASSERT'. Because of this, never use a method that changes the state of the program as the expression or part of the expression of 'ASSERT'. In a release build, 'ASSERT' is not included in the code.
Code:
class foo
{
int n;
public:
foo() : n(0) {}
void getN() const {return n;}
bool incrementN()
{
n++;
return true;
}
};
int main()
{
foo _foo;
ASSERT(0 == _foo.getN()); // OK, the state is not altered
// a call to incrementN() is supposed to follow, which alters the state
ASSERT(_foo.incrementN()); // WRONG, works only in Debug; in Release incrementN() never gets called
}
Q: What should I do when I get a "Debug Assertion Failed!" message?
A: Run your application in debugger and when you get the message press Retry to debug the application. Look in the call stack window (Alt+7) and go to the first (from top down) function written by you in the stack and identify the line that triggers the assertion failure.
Q: What are common causes for assertion failures?
A: Most often it is the usage of an invalid pointer or an attempt to index an array beyond its boundaries.
Q: How can ASSERT help me with writing better code?
A: You build your application first as a debug version and only when it is finished you build the release version. 'ASSERT' help you identify the errors in the execution flow. You should always test pointers for validity:
Code:
void Draw(int index)
{
CFigure* pFigure = GetFigure(index); // should return a figure from a list
// if GetFigure returns NULL the next line of code is faulty
pFigure->Draw ();
}
The correct way is:
Code:
void Draw (int index)
{
CFigure* pFigure = GetFigure(index);
ASSERT(pFigure != NULL); // if pFigure == NULL you get an error message
if(pFigure == NULL) // this avoids the usage of a NULL pointer
return;
pFigure->Draw ();
}
In this example I consider GetFigure() a function that should always return a valid figure. The role of ASSERT is to ensure that GetFigure() actually does what it supposed to do and always return a valid pointer. Now if you wander what is the role of
Code:
if(pFigure == NULL) return;
the answer is to make sure that if the Debug build wasn't tested enough and an error could occur in the Release, the program wouldn't crash because of the use of a NULL pointer.
However, if GetFigure() can return a NULL pointer, that pointer should not be asserted against NULL.
You should also test the index used for accessing elements of arrays:
Code:
// this is a dummy example
class foo
{
int elements[10];
public:
foo() { /* do some initialization */ };
int getAt(int index) const
{
ASSERT(index>=0 && index<10);
if(index>=0 && index<10)
return elements[index];
return -1; // return a default value
}
};
