Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk