Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-04-13 08:01:42

From: "Jesse Jones" <jesjones_at_[hidden]>

> At 6:44 PM +0300 4/12/01, Peter Dimov wrote:
> >The options for the documented interface of a function, as I see them,
> >
> >[1] f() throws if X;
> >[2] f() calls precondition_violation if X;

After giving this some thought, I'd add

[2.5] f() uses BOOST_ASSERT(~X);

where BOOST_ASSERT does the appropriate thing when BOOST_DEBUG is defined
and is (void)0 otherwise. (BOOST_DEBUG instead of NDEBUG or _DEBUG to avoid
ODR violations by mistake.) The "appropriate thing" should include calling a
user handler, if installed, but should probably not include throwing an


> >[3] the behavior of f() is undefined if X.
> >
> >Having precondition_violation won't make the question of choosing among
> >three magically go away, however. :-)
> >
> >Note that I think that [2] should work the same in debug or release
> >with the possible exception that the default handler may do different
> >things. The check should not disappear.
> If I understand you correctly you're saying that the code should
> evaluate a predicate and call a function which will dispatch to some
> handler if the predicate is false. And the function call will always
> be made, although the handler may be nil.

Sort of. boost::precondition_violation should never return, so the handler
may not be nil. (If it returns the library would probably crash.) It will by
default perform the equivalent of assert(0). The only way to recover would
be to throw an exception.

Basically, the same as assert, but does not disappear in release and the
handler may throw.

> Would you do the same with post-conditions? With invariants?

_I_ wouldn't - if a post-condition or an invariant is not met, this is a bug
in the library, not in the user code. This (hopefully) should never happen.

> What if
> a check isn't constant time?

[2.5] or [3], I guess.

Peter Dimov
Multi Media Ltd.

Boost list run by bdawes at, gregod at, cpdaniel at, john at