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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-04-14 08:11:19

From: "David Abrahams" <abrahams_at_[hidden]>

> How is using BOOST_DEBUG less mistake-prone than NDEBUG?

Clicking the wrong checkbox by mistake won't define BOOST_DEBUG. :-)

Apart from that, BOOST_DEBUG and NDEBUG would have different meanings;
BOOST_DEBUG would turn on library-level checks, and !NDEBUG would turn on
user-level checks.

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

Hmm. The intent was to separate 'costly' checks from 'free' checks. The user
must have a mechanism to make 'costly' checks disappear in release; I guess
that it's possible to provide a similar mechanism for disabling the 'free'
checks, although I don't see why I would want to disable them.

In short, I'm saying that we should have two BOOST_PRECONDITIONs, one for
situations where it's likely to have a performance impact in release, and
one for places where it can safely be left on, even in high-perf code.

I see scoped_ptr::operator*() as an example of a 'costly' check and
function::operator()() as a 'free' check.

--
Peter Dimov
Multi Media Ltd.