Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2007-08-27 10:06:16

on Sun Aug 26 2007, Beman Dawes <> wrote:

> David Abrahams wrote:
>> on Fri Aug 24 2007, Howard Hinnant <> wrote:
>>> The above appears to be a reasonable and valid use case to me for
>>> "correcting" the condition/mutex binding. The retooling operation is
>>> a rare (exceptional) event. Using exceptions for this makes the main
>>> processing routine simpler/cleaner as it does not have to deal with
>>> the complication of retooling.
>>> In summary, we have valid use cases for both not checking condition/
>>> mutex consistency, and for checking condition/mutex consistency, with
>>> both use cases built on "correctness" concerns as opposed to
>>> "performance" concerns. Where this leads us next, I'm not yet sure...
>> This is exactly the sort of use case in which I'd want to have
>> complete control of detecting the need for an exception and throwing
>> it myself. And, as described in, if you
>> rely on the std's checking and exception here you end up with the same
>> exception representing a severe programming error in one part of the
>> program and an expected, recoverable condition in another. At some
>> point up the call stack, you don't know which is which. I would
>> always want a specific "retooling" exception for the non-error case.
>> And, I repeat, when the mutex mismatch *does* represent an error, I
>> *really* don't want a mandated throw.
> So would you like to see two classes?

Probably not (see below).

> One (Peter suggested "condition") that asserts on mutex mismatch,

We don't mandate asserts in the standard.

> and another (Peter suggested "checked_condition" ) that throws on
> mutex mismatch.

I think the need for a throw is sufficiently rare that I don't want a
whole library component for it.

Dave Abrahams
Boost Consulting
The Astoria Seminar ==>

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