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
> > 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk