[boost] Re: Move semantics (was: Boost.Threads Locking Dilemma)

From: David B. Held (dheld_at_[hidden])
Date: 2002-05-16 11:52:28

> "William E. Kempf" <williamkempf_at_[hidden]> wrote in message
> news:OE55U5U9Fo2qw3iSbq90001188e_at_hotmail.com...
> [...]
> The std::auto_ptr<> template solves a similar issue through "ownership"
> and "move semantics" instead of the more traditional copy semantics.
> This allows you to pass a std::auto_ptr<> out of one "scope" and into
> another, passing the ownership and insuring only one "ptr" will ever
delete
> the object.
> [...]

This doesn't have anything to do with threads, but it's interesting that
you found another possible use for move semantics.  I'm not sure if
you could create the lock you need out of a policy-based smart pointer,
but I think it addresses a point Peter made earlier.  Basically, he said
that he never saw anyone create a custom smart pointer that looks or
feels like auto_ptr or shared_ptr.  Perhaps that's simply because we
don't have enough experience with move semantics, and we're just
now discovering where they can be useful.  It is also interesting to note
this case in light of Peter's offhand dismissal of move semantics in
response to Howard's RFC on the subject.  Absence of evidence isn't
evidence of absence. ;)

I don't know a whole lot about threads and locking, but I would be
happy to try to create a smart pointer policy for ScopedLock.  If I
understand correctly, ScopedLock is essentially an RAII wrapper for
a mutex?  And since a policy-based smart pointer is essentially a
generic RAII wrapper of some sort, it seems possible to create
an appropriate set of policies for locking.  If move semantics were
formalized a bit more in Loki::SmartPtr, for instance, it could be used
as a generic framework by which to get move semantics "for free"
in an RAII wrapper just by specifying the appropriate policy.
Furthermore, it seems that ScopedTryLock and ScopedTimedLock
could also be built from the same policy framework, and leverage
a common ThreadLock policy to handle the common infrastructure.

Dave