Version 1.9 Build 1556

News	FAQ
Search	Home

Next: Templates Up: Coding Fundamentals Previous: Fundamental Types

Debugging Checks

[This section should change. I want to use the assertions etc. as in the Usenix 1992 C++ proceedings. If anybody wants to jump in and do this please let me know!]

There are certain kinds of checks that are too expensive to be made when a program is in routine production, but are useful to turn on while debugging or writing code. At the moment these are implemented by using the symbols AIPS_DEBUG and aips_debug.

If the preprocessor macro AIPS_DEBUG is defined during compilation, then aips_debug is a global Bool variable whose value is inititialized to True. If AIPS_DEBUG is not set, then aips_debug is just defined to be (0) so that optimizers should be able to remove this during dead-code optimizations. Thus code like:

   if (aips_debug) {
     if (some_condition)
        throw(SomeError);  // or whatever
    }

should be cheap. If the debugging might happen very commonly in very tight loops you might instead want to enclose your checks in

#ifdef AIPS_DEBUG
     if (some_condition)
        throw(SomeError);  // or whatever
#endif

just to be absolutely sure there is no runtime cost.

It is useful to be able to check the invariants of a class. To do this a useful convention is to define virtual Bool ok() const in classes. This function should check that the class state is consistent. This would be particularly useful if used in conjunction with aips_debug to consistently check the invariants of a class in every member function.

Note: The assert.h macros should not be used other than in test programs because:

1.: They will unconditionally exit whereas all real code should have the possibility of error recovery.
2.: They have been observed not to work under some circumstances (because ANSI token catenation has not made it into all preprocessors in a consistent way).

Next: Templates Up: Coding Fundamentals Previous: Fundamental Types Contents Index