"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
004f01c2c921$aae010b0$1d00a8c0@pdimov2">news:004f01c2c921$aae010b0$1d00a8c0@pdimov2...
> From: "David B. Held" <[EMAIL PROTECTED]>
> >
> > 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
