Boost logo

Boost :

From: Darryl Green (green_at_[hidden])
Date: 2002-05-19 19:56:25

> -----Original Message-----
> From: William E. Kempf [mailto:williamkempf_at_[hidden]]
> Then how about a variation on the auto_ptr interface.
> Instead of using the
> same syntax for "move semantics" as you would for "copy semantics" the
> ScopedLock can provide a "move" operation that returns a
> proxy for which
> another ScopedLock may be constructed from. So this:
> ScopedLock lock1(mutex);
> ScopedLock lock2(lock1);
> would be illegal while this:
> ScopedLock lock1(mutex);
> ScopedLock lock2(lock1.move());
> would provide auto_ptr like move semantics. If we choose the
> right name for
> "move" this could discourage users from "passing locks"
> unless it's needed
> and the code is self documenting exactly what's occuring,
> unlike the syntax
> for auto_ptr move semantics. Would this be more pallatable?

The move proxy is a great solution. It preserves all the good features of
the existing ScopedPointer while allowing move in a way that I don't find
any uglier than the alternatives (ok, it is uglier than the auto_ptr option,
but the auto_ptr's beauty seems to be a bit treacherous).
> (If so, I
> still question whether or not this totally resolves issues
> with needing
> lock/unlock in different "scopes").

I assume the question applies equally to the auto_ptr model? Or am I missing
something? I did think about this when looking at your original RFC, but I
couldn't think of a case it didn't deal with - not that that proves much.

> Does the above syntax work for you in this regard? If not,
> do you have any
> thoughts on how else to expose this?

It certainly does.

Darryl Green.

Boost list run by bdawes at, gregod at, cpdaniel at, john at