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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-05-18 04:06:59

From: "David B. Held" <dheld_at_[hidden]>
> "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.

Can't the design be improved? Small changes in behavior should correspond to
small changes in implementation, or to put it another way, less code.

> > 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.

Yes, it's an apples/oranges comparison, I account for that. :-) A true
auto_ptr counterpart cannot have a 'lock' method. An auto_ptr is "locked"
when its stored pointer is not NULL, and "unlocked" otherwise; you can't
re-lock it. That's what I'd expect from an auto_lock, too, if I had to judge
it by its name only.