From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-08 11:40:23
Eric Niebler wrote:
> 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
> 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?
Well, I was thinking of getting a design working that didn't require the
lock being movable, then making it movable later. But if being movable
is necessary for the design, it makes sense to consider it now.
Actually, considering that that the promotion/demotion of read-locks and
write-locks is similar to moving (when you promote by constructing a
write-lock from a read-lock, it "moves" the lock), maybe it makes sense
to consider it now anyway.
There have also been requests from time to time for transferable locks,
so it's something I would definitely like to address eventually. There
was even a discussion once about implementing them once (for example,
Would Boost.Move (in the Sandbox, I guess) help with this?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk