"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
