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

From: David B. Held (dheld_at_[hidden])
Date: 2003-01-29 16:55:06

"David Abrahams" <dave_at_[hidden]> wrote in message
news:u8yx3hcp2.fsf_at_boost-consulting.com...
> [...]
> Then you've indeed got a problem.  There were indications in
> some of Beman's earlier explorations that the orthogonal policy
> decomposition wasn't always a natural one.  This might be another
> clue.

Indeed.  My new suggested change involves breaking orthogonality
in a way that I think even Beman suggested, if memory serves me
correctly.

> > [...]
> > smart_ptr(T* p)
> > try
> >     : storage_policy(p), ownership(p), conversion(), checking()
> > { ... }
> > catch
> > {
> >     storage_policy::destroy();
>
> This looks like a static member function call.  How does it get ahold
> of p?

Yes, it *looks* like a static member. ;)  But remember that
storage_policy is a base, so this is also a valid member function call,
and destroy() is a non-static member of storage_policy.  Of course, the
call to destroy() only succeeds if storage_policy(p) has succeeded.

> IIRC one of the reasons function-try-blocks are often useless is that
> the data members are already gone, so you can't touch them.

Yup. 15.3.11.  That does make them incredibly useless.

> [...]
> And conversion and checking, no?  If one of those fails, don't you
> want the regular release sequence you cite above to take effect?

Yes, but who in their right minds is going to write a custom conversion
policy? ;)  The ones provided are explicitly no-throw.  However,
checking will probably throw exceptions in some configurations, and
requiring them to be no-throw would defeat the point of having the
checking to begin with.

> [...]
> Me neither, other than changing the design.

I think by parameterizing the policies on storage_policy<T>, rather
than storage_policy<T>::pointer_type is the solution.  It breaks
orthogonality, but in the most minimal way I can imagine.  It gives
the other policies the ability to tell storage_policy to clean up, but
introduces no other dependencies.  If I recall correctly, this is
exactly the design Beman settled on (or something close, where
storage_policy was a central point).

Dave