Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-03-20 15:25:22


> -----Original Message-----
> From: Greg Colvin [mailto:gcolvin_at_[hidden]]

>
> From: <williamkempf_at_[hidden]>

>
> > BTW, while on the discussion of a BOOST_ASSERT (or better name), we
> > should also address one of the big issues with the C assert that's
> > not been brought up yet. To illustrate the problem, while adding
> > assertions to Boost.Thread I've run into code that you naturally want
> > to write like this:
> >
> > assert(pthread_mutex_lock(&mutex) == 0);
> >
> > which is, of course, a bug. When compiled with out NDEBUG the code
> > is reduced to a no-op, which means the mutex is never unlocked. So
> > you wind up having to code the more verbose:
> >
> > int res = pthread_mutex_lock(&mutex);
> > assert(res == 0);
> >
> > which just makes the code harder to read and maintain. MS did
> > something right in this regard in their MFC library where they have
> > an ASSERT() which is similar to the classic C assert and a VERIFY()
> > which retains the expression in builds without NDEBUG but does not
> > halt the program if the expression evaluates to false.
>
> Yes, this is good.

Actually, I disagree. IMO, the stuff in assert() is very easy to separate
from the mainline code. Everyone must follow the rule "no side-effects in
assert" anyway. Adding a VERIFY() macro just gives us another macro to keep
track of. How does it help in any substantive way?

-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk