Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-03-20 14:47:18

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

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.

Bill Kempf

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