From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2007-08-25 14:48:36
On Aug 25, 2007, at 2:11 PM, Peter Dimov wrote:
> I'll wait for this hypothetical client to appear.
So if we were targeting boost, or even TR2, we would have this
luxury. We're not and we don't. We need to get it right the first
time. Failing strong consensus of what is "right", we're going to get
the current boost::condition. I'm not even positive how to interpret
the spec for boost::condition: either mutex-only, or generalized, but
definitely not both since it isn't templated.
> To try to provide a summary: we have three conditions on the table:
> unchecked, (2) possibly checked, and (3) checked. Your original
> design has
> (3) as default, (1) when the mutex argument is wrapped by
> unchecked<>. The
> direction you now seem to be exploring is (1) by default, (3) as an
> which I regard as a regression. I suggest (2) by default, with (3)
> as an
> option, but only if there proves to be demand.
Nice summary. I'm very opposed to (2). It says:
Here's a constructor and the only difference between it and the other
constructor (or other form of the same constructor) is that it adds a
bunch of undefined behavior.
That just can't be a good thing to put into a standard.
> Regardless of what is chosen, I maintain that the three conditions
> syntactically have the same interface, that is, it must be possible
> to pass
> a mutex even to (1). It would be painful to switch between them if
> they do
I've actually been doing this switching a lot recently in my prototype
and associated test code. It isn't that painful. But I agree it
would be nice to not have to do it at all. If we only manage to
standardize (1), then justifying a constructor that looks different
but has no difference in behavior is hard to justify. If we manage to
standardize both (1) and (3), then it becomes much easier to justify
such a constructor.
I'm strictly looking at this from the client's point of view. I'm the
client. I know what I want, and I want to be able to pick something
and know what it does. I don't want to be stuck with something that
maybe does something, and maybe not. It's like buying something with
absolutely no warranty.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk