From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-03-20 15:08:16
> --- In boost_at_y..., Kevlin Henney <kevlin_at_c...> wrote:
> > In message <030b01c0b108$9dbcba60$37781990_at_u...>, Greg Colvin
> > <gcolvin_at_u...> writes
> > >> As indeed a straight call to std::unexpected will do. What am I
> > >
> > >A way to communicate what the error is to the unexpected_handler?
> > Of course. The hack goes much deeper than the code you showed :->
> It's a
> > little early, I guess I need more coffee before reading between the
> > lines 8-)
> For some applications this hack is beautiful! However, for a Boost
> solution I don't know if I like it. You can no longer use the
> unexpected_handler for what it was meant for while at the same time
> having a configurable "assert". I'm not sure how this might effect
> real world applications, but it makes me nervous.
I've never yet seen a real world application of unexpected_handler,
but perhaps someone here can enlighten me.
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk