From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-04-13 15:48:07
At 4:01 PM +0300 4/13/01, Peter Dimov wrote:
>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,
>> > f() throws if X;
>> > 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
>Or perhaps we should have BOOST_PRECONDITION, BOOST_POSTCONDITION, and
I'd lean towards doing that.
> > > 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  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.
I see. I think that I would be OK with this, but I'm a bit disturbed
that there is no way to disable the checks in release. With a bit of
care I don't think this would be too much of a problem, but I think
there will be a significant psychological barrier among a lot of
>> 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.
Better watch for the bottom when you get on those slippery slopes! :-)
> > What if
>> a check isn't constant time?
>[2.5] or , I guess.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk