VC++/MFC

Visual C++ Debugging: How to use 'ASSERT' and deal with assertions failures?

Sat, 24/02/2007 - 10:27 — admin

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

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.

: 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.

ASSERT_KINDOF(CMyDocument, pDocument)

if identical with

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':

#include <assert.h>
int main()
{
int* array = NULL;
assert(array != NULL); // this should fail
return 0;
}

output is:

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.

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:

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:

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

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:

// 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
}
};

Note: Most of the material in this article is taken from codeguru.com

Recommended Reading :

VC++/MFC

Login or register to post comments

Visual C++ DLL: How to build a resource-only DLL?

Sat, 24/02/2007 - 10:26 — admin

VC++/MFC

Login or register to post comments

Visual C++ Debugging: How do I evaluate the time difference between two events?

Sun, 18/02/2007 - 20:47 — admin

VC++/MFC

Login or register to post comments

Visual C++ Network: How to get the local IP address(es)?

Sun, 18/02/2007 - 20:46 — admin

VC++/MFC

Login or register to post comments

Visual C++ Network: How to get the local hostname?

Sun, 18/02/2007 - 20:44 — admin

VC++/MFC

Login or register to post comments

Visual C++ DLL: How to build a DLL to be used from another programming language?

Sun, 18/02/2007 - 20:43 — admin

Q: How to build a DLL to be used from another programming language?

A: When you create a DLL with Visual C++, and you want to use the DLL with other languages, there are a few things that you should do (creating a DLL isn't just compiling code).

Make sure your exported functions are declared as extern "C". The reason for this is so that the C++ name mangling is not used on the exported function names.
Make sure your exported functions use '__stdcall' calling convention. The reason for this is that most other Window's languages assume the exported functions retrieve parameters starting from the rightmost parameter, and that the function called is responsible for stack cleanup on return. By default C and C++ functions assume '__cdecl' calling convention.
You won't know when this problem exists until you call the exported function in your Delphi program. You did not declare
your function as '__stdcall', so your [insert porgramming language, other than C/C++, here] program would have crashed as soon as you called the function.
Use '__declspec(dllexport)'. This is so that the function can be exported (of course).
Use a module definition file (.def-file). This removes the "@x" decoration that appears at the end of VC++ exported function names, where "x" is the total number of bytes in the arguments passed to the function. When the user of the DLL is using another language, the programmer would rather call "tempest", not "tempest@4". Yes, many of these other languages have an "aliasing" features so that you can access the function by a different name, but it is a pain in the neck. Just use a .def-file to remove the additional decoration and you won't have to do anything else.

Note: Just exporting the name does *not* remove all the decoration - you must follow steps a) *and* d). A lot think that you only need to do a) and b) and c). This is if you plan on using the DLL in only Visual C++. If you leave the module definition file out of these steps, you will get what you're seeing now -- an exported name that is not what you expect.

If you do a search on CodeGuru, your question has been asked many times in various ways, and the reason for the problem is almost always that step d) was left out.
Here is a sample of a module-definition fie (DEF file).

LIBRARY YOURDLL
DESCRIPTION 'This is my DLL
EXPORTS
Whatever1 @2
Whatever2 @3

The LIBRARY command must match the name of your DLL. So if your DLL is named YOURDLL.DLL, the LIBRARY command is followed by YOURDLL.

The DESCRIPTION is any description you feel is appropriate for your DLL. The actual description is preceeded by a single quote (').

The EXPORTS lists the functions that you exported, along with an ordinal number. It doesn't matter what ordinal numbers you use, so long as you maintain different numbers for each function, and you shouldn't change the ordinal numbers when you create an upgraded version of your DLL -- persons preferring to use ordinal numbers to call your functions will get angry.
Note: Most of the material in this article is taken from codeguru.com

Recommended Reading :