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.