C++ Preprocessor: Always Assert Your Code Is Right - Implementing a Simplified Assert
(Page 3 of 4 )
Although I am ranting about why you should use assert, this article is aimed at showing you how to implement your own version using preprocessor macros.
Here is a very basic version that doesn’t even halt execution:
#ifndef NDEBUG
# define ASSERT( isOK ) \
( (isOK) ? \
(void)0 : \
(void)printf(“ERROR!! Assert ‘%s’ failed on line %d ” \
“in file ‘%s’\n”, #isOK, __LINE__, __FILE__) )
#else
# define ASSERT( unused ) do {} while( false )
#endif
Notice that we don’t need a helper function to get information onto the screen. (I am sticking to printf in the following examples, but there is nothing stopping you from using fprintf and stderr instead.) The stringize macro operator (#) names the condition for us in the printf statement, adding quotes as well and the predefined __LINE__ and __FILE__ macros help to identify the location of the assert.
The do { } while ( false ) statement for the unused version of assert, I used to make sure that the user cannot forget to conclude his assert statement with a semicolon. The compiler will optimize it away, and I consider it a slightly better way to say that I am not doing anything.
We are only one step away from halting our application’s execution (don’t forget to include stdlib.h):
#ifndef NDEBUG
# define ASSERT( isOK ) \
if ( !isOK ) { \
(void)printf(“ERROR!! Assert ‘%s’ failed on line %d “ \
“in file ‘%s’\n”, #isOK, __LINE__, __FILE__) ); \
abort(); \
}
#else
# define ASSERT( unused ) do {} while ( false )
#endif
In case writeString is called with a NULL pointer now, we are told what went wrong, where it went wrong and the application is halted.
When you are using the Microsoft Visual C++ 7.1 compiler, you’ll be presented with a dialog screen:

After pressing Retry you are presented with more dialogs and finally... you end up in the debugger.
The problem with abort() is that it doesn’t let you resume execution after you’ve concluded that the assert was benign; or maybe you are interested in what happens immediately after the assert? You need to disable the assert (never a good thing), recompile and restart your application.
There are other ways to halt execution and you will have to look in your compiler’s documentation to discover what the correct call is, but with Visual C++ it’s an interrupt call:
__asm { int 3 }
When our application halts again on the writeString function, we’ll encounter the following dialog (did you recognize it? We actually came across this dialog when halting the application with the abort() function!) :

It is not a problem to continue execution now, if we think this is responsible… that is you are often recommended to implement your own assert functionality.
Wouldn’t it be nice to be able to add some hints or remarks along with the location of the assert? When the assert fires and you don’t have a debugger available, this message might still tell you what the problem is:
void writeString(char const *string) {
assert(0!=string, “A null pointer was passed to writeString()!”);
...
}
Next: Refining Assert >>
More C++ Articles
More By J. Nakamura