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

From: David B. Held (dheld_at_[hidden])
Date: 2002-05-17 14:22:59

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:003c01c1fdbf$047e6e20$1d00a8c0_at_pdimov2...
> [...]
> That's a lot of code!

True. :(

> Part of it is probably caused by the non-"standard"
> (stored|pointer|reference)_type, but still.

I'm afraid that a policy-based design does trade some simplicity for
power.  I guess it's a lesson learned about more generic uses of
SmartPtr.

> An entity that is that close to std::auto_ptr<M> (only the deallocator
> is different) should be simpler to build using the framework (which
> presumably can duplicate std::auto_ptr out of the box) - or am I
> missing something?

Well, it's possible that the default policies could be made more
generic.  It would be nice to be able to reuse destructive_copy, but
I'm not sure if it can be made sufficiently general.  Looking at it now,
a Move policy could probably act as a basic move-semantics base
class, from which destructive_copy and lock_move could both
derive, since the only difference is the clone() implementation.
Then, the bulk of the implementation would be the Storage policy,
which more or less makes sense.

Also, if you look at the implementation of ScopedLock, you will
see that it is slightly more complex than std::auto_ptr.  In particular,
it exposes a locked() accessor.  Also, my policy is not as efficiently
written as possible.  I created separate lock() and unlock() functions,
like ScopedLock, when I could have inlined them in the only places
where they are actually called.  That makes the code look bigger
than it ought to.  Otherwise, it really wasn't that much work.  I wrote
the stuff in about 20 minutes, most of which was to familiarize myself
with how ScopedLock works.

I might point out that the policy design does allow you to choose
different Ownership semantics, including the classic no_copy
semantics, and all manner of shared semantics.

Also note that the family of locks can be built from the same set
of policies if a base lock policy were written on which the various
lock policies can be built.  Of course, the extant lock implementations
could use the same trick.  The primary benefit of the policy-based
approach is that it allows for flexibility in ownership semantics.

Dave