[boost] Re: [policy_ptr]

From: David B. Held (dheld_at_[hidden])
Date: 2003-10-30 15:01:37

<cppljevans_at_[hidden]> wrote in message
news:bnr3b8$d0j$1_at_sea.gmane.org...
> > [...]
> > However, the shared_storage template class has a reference
> > count; hence, it seems like it ought to be an OwnershipPolicy
> > since the above OwnershipPolicy defaults to ref_counted.  So
> > should shared_storage be renamed as shared_ownership?

Well, it's tricky, because of the way shared_ptr does things.  It
stores both the count and the actual pointer in a count object.
If you look at the smart_ptr policy interface, that pointer pretty
much has to be in a Storage policy.  So no, it shouldn't be an
Ownership policy.

> I beginning to think Ownerhship and Storage should be merged
> into a general template, OwnerStoragePolicy, that can be
> specialized based on the Ownership and Storage policies.

This has been discussed before.

> The shared_storage and my policy_referent_ptrs.hpp file
> which I recently uploaded in the cyclic_smart_ptr.zip file
> both support this conclusion.  Also, I'm thinking that if the
> Ownership pointer and scalar_storage pointer are the
> same, then that's an intrusive pointer; hence, the
> specialization would be an intrusive pointer.

Not sure what you're getting at here.  Would you elaborate?

> I also tried deriving a refcycle_counted from the policy_ptr
> ref_counted and discovered it would be easier if these 2
> policies were merged.

I would have to look closely at your policy to render an opinion.

> It seems maybe that was anticipated when you put both in the
> same branch of the optimally_inherit branch of the smart_ptr
> super class.  Does that sound right?

Actually, the resource_manager class is an exception safety
device.  Indeed, the Ownership and Storage policies are not
100% orthogonal.  The Storage policy needs to know whether
it *can* delete the resource.  This is handled by smart_ptr,
which coordinates.  But to improve exception safety, it was
better to coordinate at a lower level than smart_ptr itself.  The
reason they are different policies is because they *are*
orthogonal, just not 100%.  Maybe 90%.  For me, the killer
example is scalar_ vs. array_storage.  Do you really want
to specialize all 7 default ownership policies for both of these
storage policies???  That goes from 9 policies to 14.  And
if we throw in any more storage policies, it goes up by a
factor of seven.  That's more than a 50% increase in the
number of policies, and far more than a 50% increase in
the amount of code, because of all the duplication.

The whole point of policy-based design is to factor out the
common code, and merging storage and ownership policies
seems to work against that.  If you can describe a unified
interface that doesn't resort to a return to a combinatorial
number of policies, I'm all ears.  If not, then I think an
occasional dummy policy (like boost::ref_counted) is
appropriate.

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.532 / Virus Database: 326 - Release Date: 10/27/2003