[boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue

From: David B. Held (dheld_at_[hidden])
Date: 2003-01-31 10:54:14

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:004f01c2c921$aae010b0$1d00a8c0_at_pdimov2...
> From: "David B. Held" <dheld_at_[hidden]>
> >
> > smart_ptr(P p)
> >     : storage(p), ownership(p), checking(), conversion()
> > { checking::on_init(p) }
>
> smart_ptr(P p)
>     : storage(p), ownership(p), checking(p), conversion()
> {}
>
> is nicer. Maybe even conversion(p), for consistency. :-)

Well, if you want consistency, "on_init(p)" is better. ;)  Technically,
one could argue that you might want checking to occur *after* the
other policy c'tors have completed.

> But that's not what I have in mind. There are a number of pitfalls
> awaiting you.

Tell me something new. :(

> Consider the converting move constructor:
>
> smart_ptr(smart_ptr & rhs)
>     : storage(rhs), ownership(rhs), checking(rhs), conversion(rhs)
> {}
>
> Its purpose is to take ownership away from the auto_ptr-like rhs
> (you wanted to support that) and construct a counted_ptr.

Hmm...I'm not so sure about constructing a ref-counted pointer from
a move pointer.  That's an interesting idea that I hadn't really
considered.  I'm not sure whether it's a good idea to allow that or
not.  It might encourage indiscriminate mixing of pointer types.

> As storage is constructed first, it needs to move from rhs.storage;
> now when ownership throws, rhs.storage will be left empty, and the
> object is gone. This is not that big of a problem... provided that the
> other rhs policies can handle storage being zeroed.

They'd better be able to handle this, since is this is what would
happen in the *non-exceptional* case as well.  However, the other
policies had better not be able to tell whether or not storage is zeroed,
or we have lost orthogonality.

A more interesting related problem involves what to do when
transferring a managed resource.  When tranferring an unmanaged
resource, you have to clean it up on an exception, just to get the
basic guarantee.  However, when moving from a managed pointer,
cleaning up will only *get* you the basic guarantee.  To get the
strong guarantee, you need to *move the resource back*.  This is a
tricky situation that might be a good argument to not support move
semantics. ;)  Or maybe the strong guarantee isn't important for this.
I dunno.  Comments?

> [...]
> In short, trying to support auto_ptr, shared_ptr, and weak_ptr will
> either destroy the design, or make it stronger. :-)

Well, considering there isn't a configuration of "the runtime Borg" for
weak_ptr, I wouldn't feel too bad not supporting it internally.
Besides, weak_ptr isn't even "smart" to begin with. ;)  We'll cover
that with a policy-based "DumbPtr". ;>

Dave