Gotcha #28: Side Effects in Assertions
I don't like many of the ways in which #define is used, but I do put up with the standard assert defined in <cassert>. In fact, I encourage its use, provided it's used properly. Proper use is often the problem.
There are many variations, but the assert macro is usually defined something like this:
 gotcha28/myassert.h
#ifndef NDEBUG
#define assert(e) ((e) \
? ((void)0) \
:__assert_failed(#e,__FILE__,__LINE__) )
#else
#define assert(e) ((void)0)
#endif
If the NDEBUG symbol is defined, then we're not debugging, and assert is a no-op. Otherwise, we're debugging, and assert expands (in this implementation) to a conditional expression that tests a condition. If the condition is false, we produce a diagnostic message and abort.
Use of assert is generally superior to that of comments for documenting preconditions, postconditions, and invariants. An assert, if enabled, performs a runtime check on these conditions and so cannot be as easily ignored as a comment (see Gotcha #1). Unlike comments, asserts that become invalid are usually corrected, since the invocation of abort is a potent reminder of the need for maintenance:
gotcha28/myassert.cpp
template <class Cont>
void doit( Cont &c, int index ) {
assert( index >= 0 && index < c.size() ); // #1
assert( process( c[index] ) ); // #2
// . . .
}
In the code above, however, we're misusing the assert facility. The line marked #2 is an obvious misuse, since we're calling a function that may have a side effect from within an assert. The behavior of the code will be substantially different, depending on whether the NDEBUG symbol is set or not. This use of assert could result in correct behavior while debugging and a bug when debugging is turned off. So you'll turn on debugging and the bug will disappear. Then you'll turn off debugging, and …
The line marked #1 is more nuanced. The size member function of the Cont class is probably a const member function, so it should have no side effect, right? Wrong. Nothing except the conventional meaning of size promises const semantics. Even if the size function is const, there's no guarantee that calling it will not have a side effect. Even if the logical state of c is unchanged by the call, its physical state may be (see Gotcha #82). Finally, keep in mind that assertions are for catching bugs. Even if calling size isn't intended to have a discernible effect on the code's subsequent behavior, its implementation may contain a bug. We'd prefer that our uses of assert uncover bugs rather than hide them. Proper use of assert avoids even a potential side effect in its condition:
template <class Cont>
void doit( Cont &c, int index ) {
const int size = c.size();
assert( index >= 0 && index < size ); // correct
// . . .
Assertions are not a cure-all, obviously, but they do occupy a useful niche situated somewhere between comments and exceptions for documenting and detecting illegal behavior. The major drawback to assertions is that assert is a pseudofunction and is therefore subject to all our earlier provisos about pseudofunctions (see Gotcha #26). However, it does have the advantage of being a standard pseudofunction, with the implication that its failings are well known. When used with caution, assertions can be of value.
|
