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. :-)
But that's not what I have in mind. There are a number of pitfalls awaiting
you.
Consider the converting move constructor:
smart_ptr(smart_ptr & rhs)
: storage(rhs), ownership(rhs), checking(rhs), conversion(rhs)
{}
(template parameters omitted for brevity)
Its purpose is to take ownership away from the auto_ptr-like rhs (you wanted
to support that) and construct a counted_ptr. 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.
Weak pointers are another interesting case, assuming you want to support
them. A weak_ptr storage can't be copied safely, as the pointer may have
been deleted. If you look at shared_ptr::shared_ptr(weak_ptr const &),
you'll see that it copies the count first (its "ownership policy"), and then
proceeds to copy px (its "storage policy"). weak_ptr's converting
constructor does something similar.
Also:
smart_ptr::~smart_ptr()
{
if (!ownership_policy::release(get_impl(*this)))
{
storage_policy::release();
}
}
It's difficult to supply a get_impl for a weak pointer, since the returned
pointer can be invalidated at any time by a different thread. That's why
weak_ptr doesn't have (no longer has) one.
In short, trying to support auto_ptr, shared_ptr, and weak_ptr will either
destroy the design, or make it stronger. :-)
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
