Peter Dimov wrote:
Michael Glassford wrote:
I agree that movable locks should wait. However, what about something like this, which doesn't require movable locks (concept only--there are probably errors):
[...]
Looks like Comeau in strict mode would still not accept it; noncopyable objects cannot be copy-initialized. But let's get back to my original question:
See the code I posted with my movable lock. It is noncopyable but you can return it from a function and use copy-initialization so you can declare your locks in an "if" statement. It compiles with Comeau strict.
One might argue that a lock is naturally moveable... but I think that we should constrain ourselves to (fixing) the current noncopyable scoped_lock idiom.
Should we consider alternate designs only after the fixed scoped_lock has achieved wide acceptance? After it has been proposed for standardization? After it has been accepted? If you're talking about making breaking changes to the threading library (aren't you?), isn't the time to consider alternate designs now? -- Eric Niebler Boost Consulting www.boost-consulting.com