Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-08-26 11:39:42

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?

One (Peter suggested "condition") that asserts on mutex mismatch, and
another (Peter suggested "checked_condition" ) that throws on mutex

Or would you prefer only "condition", but with one or more additional
signatures that take an additional argument that says, in effect, "throw
rather than assert on mutex mismatch?


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