Re: [boost] Re: any_function (callback) library

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-04-13 09:56:55

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, April 13, 2001 9:01 AM
Subject: Re: [boost] Re: any_function (callback) library

> 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,
> are:
> > >
> > >[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.)

How is using BOOST_DEBUG less mistake-prone than NDEBUG?

> The "appropriate thing" should include calling a
> user handler, if installed, but should probably not include throwing an
> exception.

I'm OK with that.

> Or perhaps we should have BOOST_PRECONDITION, BOOST_POSTCONDITION, and
> BOOST_INVARIANT.

That too.

> 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.

That would mean that high-performance code could never use
BOOST_PRECONDITION.
I don't like this at all.
A premise of using assertions is: never make the programmer concerned about
the impact that doing an assertion may have on his code's performance. If
you do, people won't use assertions.

-Dave