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