Boost logo

Boost :

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-05-01 11:39:39


Hi,

I do not like to do a design decisions (here I completely agree with Andrei
in his recent post on the topic). I do not know how useful or widely used is
weak_ptr, but we should be able to accommodate this idea. Here what I am
thinking:

1. weak_ptr (from now on I will call it weak_reference ) defer from original
smart_ptr only in type of ownership. I.e. all other characteristics of it,
like access right and storage are the same.
2. People who gonna need weak reference should agree on some overhead
3. People who are not gonna need weak reference should not be affected.

It seems from this that we need pair of coworking ownership policies
ref_counted_with_weak_ref_support and weak_reference_ownership. They will
now how to convert to each other and cowork to achieve desired effect.

Now the only question that is left (other then mentioned policies
implementation ) is how to connect them.shared_ptr with
ref_counted_with_weak_ref_support ownership policy should somehow export
week_reference type that is the smart_ptr type with the same
storage,checking,conversion policies and with weak_reference_ownership
ownership policy.

There are following choices here:

1. Parameterize weak_reference_ownership with all other policies.
This would make desired smart_ptr specification a little bit awkward and
bulky, but I do not think it's a big deal.

2. We may decide that this is generic need and add subtype deduction
mechanism into the framework.
There are several ways to implement this. One is to add one more template
parameter: subtype generator. Could be another way. I open to any
suggestion.

So, let's not argue about tradeoffs, let separate policies.

Regards,

Gennadiy.


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