Boost logo

Boost :

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

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


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