From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-08-25 14:11:29
Howard Hinnant:
> What would you recommend for back porting your proposal into boost? A
> boost debug build? Or to always include the check? And why?
Boost already has a debug build and doesn't promise compatibility between
debug and release, so in this case the path of least resistance would
certainly be to #ifdef the extra pointer on NDEBUG and use BOOST_ASSERT.
On an implementation that must withstand inconsistent definitions of NDEBUG
and/or wants to include checking in release, I'd use a variation of "checked
release" from my previous post.
> Also note that I specifically showed that no matter what we do, we can
> not make it impossible for the user to explicitly associate a mutex
> with the condition:
Sure, but this doesn't help with discovering bugs in code where the user did
not associate a mutex with the condition because you made him jump through
hoops to do so. Your original design did encourage users to associate with a
mutex by default, and this was a good thing.
> On Aug 25, 2007, at 11:53 AM, Howard Hinnant wrote:
>
>> The above being said, it is easy to add a "constrained condition" with
>> a variety of syntaxes and semantics.
> ...
>> condition<constrain<Mutex>> cv(mut);
>> constrain_condition<Mutex> cv(mut);
>> constrain::condition<Mutex> cv(mut);
>>
>> All of the above syntaxes could be achieved either by the std::lib, or
>> by the client.
>
> For the client who has a use case where they want a constrained
> condition, and want to correct any mis-bindings at run time, what do
> you recommend for them?
I'll wait for this hypothetical client to appear, suggest a
checked_condition wrapper, then consider adding boost::checked_condition (or
constrained_condition if you prefer) if this proves a common occurence.
> What do you tell the client who wants to regularly change the mutex/
> condition binding, and whose design makes it impossible for there to
> be a mis-binding (because there's only one waiting thread)?
I'll wait for this hypothetical client to appear.
To try to provide a summary: we have three conditions on the table: (1)
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 option,
which I regard as a regression. I suggest (2) by default, with (3) as an
option, but only if there proves to be demand.
Regardless of what is chosen, I maintain that the three conditions must
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
not.