From: David B. Held (dheld_at_[hidden])
Date: 2003-10-30 15:01:37
<cppljevans_at_[hidden]> wrote in message
> > [...]
> > 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
> 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
--- 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk