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

From: David B. Held (dheld_at_[hidden])
Date: 2003-01-30 22:57:46

"David Abrahams" <dave_at_[hidden]> wrote in message
news:uel6ucf6w.fsf_at_boost-consulting.com...
> [...]
> That's OK if the class which ultimately takes posession of p (not
> base_type, I think, but storage... or is it ownership?) is _required_
> to take it by reference.  Does such a requirement exist?

It does now. ;)  For the most common cases, it isn't a problem,
obviously, because p will be fundamental.  For smart-resource type
applications, I still have a hard time imagining that you would want
to write a storage policy that takes a *copy* of a managed resource,
rather than the *actual resource*.  However, I will make it explicitly
clear in the docs that if you take a copy, and it throws, you will
probably leak your resource.

> [...]
> That is a very clean approach, and assuming it's OK to keep the
> the sole copy of p in storage_policy, even efficient.

I'm not sure anyone would use a pointer that kept multiple copies of
p.  Wouldn't that make it pretty fat?

> > [...]
> > Ownership may have state, but but it need only be consulted
> > when the resource could possibly be shared or moved.  That's
> > only possible if the smart_ptr c'tor has completed.
>
> I'm not sure that's true for intrusively-counted types.

Ouch. This is a serious problem that requires some thought.

Dave