From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-08-21 18:31:06
Howard Hinnant wrote:
> No, not ignoring your suggestion. Still contemplating it. Of all the
> condition suggestions I've heard (not just here, but over the past
> month or so) I like yours second best. ;-)
> I'm concerned that we would be relegating goal #3:
>> 1. Minimum size - performance overhead.
>> 2. The freedom to dynamically associate mutexes with condition
>> 3. The ability to apply run time check consistency concerning the
>> associated mutex.
>> 4. The ability to wait on general mutex / lock types.
> to a non-standard-mandated debug library. In your favor, I believe
> most current vendors are supplying debug libs. However the checks are
> not uniform. Even the error reporting mechanism isn't uniform.
In general, I don't like designs that mandate checking by specifying
behavior on error because they make incorrect programs correct. That is, it
is no longer possible for the library to loudly flag invalid uses as the
client may exploit the documented behavior and expect (or worse, ignore) the
exception. It also requires that the library catches 100% of the errors,
rather than 99.4% of them, and these last 0.6% can be expensive.
There could be legitimate use cases that require the exception. If forced, I
would probably supply checked_condition to address this need, if it proves
justified. Or I might not, as checked_condition seems trivial to write as a
wrapper over condition (unless I'm missing something - I haven't actually
prototyped the code).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk