Boost logo

Boost :

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
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 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 (
Version: 6.0.532 / Virus Database: 326 - Release Date: 10/27/2003

Boost list run by bdawes at, gregod at, cpdaniel at, john at