From: David Abrahams (dave_at_[hidden])
Date: 2007-08-27 10:06:16
on Sun Aug 26 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
> David Abrahams wrote:
>> on Fri Aug 24 2007, Howard Hinnant <howard.hinnant-AT-gmail.com> 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 http://tinyurl.com/2ph58t, 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 http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk