From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-08-25 14:11:29
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk