Boost logo

Boost :

From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-04-12 17:22:08


> > If so, what do you think of Bill Kempf's suggestion of a BOOST_ASSERT()
>> which asserted in debug mode, and is user configurable in release mode to
>> throw or not?
>
>I think there's insufficient granularity. Peter Dimov's
>boost_precondition_check suggestion is better. Ideally it should be possible
>to handle precondition checking differently from postcondition and invariant
>checking. I would just assert for postconditions and invariants.

I think this is right. However one of the options should be no
checking at all which is going to require a macro I think.

> > (I know that implies debug/throw/nothrow library builds (rather than just
>> debug/release) but let's assume we are willing to pay that cost.)
>
>Oof. I am still reluctant to add throwing behavior for precondition checks,
>though people seem to want it. Part of the problem is that many implicit
>preconditions will probably go unchecked (e.g. is someone calling a member
>function through an invalid pointer). Providing a truly bulletproof
>interface is expensive. I don't think most library designers will do it, and
>many that try will probably take half-measures.
>
Boost doesn't have to provide throwing as an option, but we should
have something flexible enough to allow this. I suggested something
like the following a while back:

#if defined(NDEBUG) && !defined(ALWAYS_ASSERT)
     #define ASSERT(p) ((void) 0)
#else
     void AssertsAbort(const char* expr, const char* file, int line);
     // write to stderr and abort

     void AssertsBreakToDebugger(const char* expr, const char* file, int line);
     // drop into the debugger if one is present, if not call AssertsAbort

     void (*gAssertFailed)(const char* expr, const char* file, int line);
     #define ASSERT(p) (!(p) ? gAssertFailed(#p, __FILE__,
__LINE__) : (void) 0)
#endif

There'd be separate macros for preconditions and postconditions, but
the idea remains the same. The only problem I see here is the ODR.
But I just can't see giving up asserts on the possibility of a ODR
problem.

   -- Jesse


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk