[boost] RFC: Inheritance alternatives for policy-based smart_ptr

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-04-29 02:14:54

Hi,

I would like to discuss and hopefully find some consensus on type of
inheritance to be used by policy-based smart_ptr. Decision could be affected
by specific problems with policies orthogonality. But since I do not have an
examples of such problems I expect some from boosters. FWIW we have at least
6 design alternatives (they were presented to boost already, I just want to
summarize here):

1. Loki::SmartPtr style. smart_ptr is inherited from polices it
parameterized with.
Even assuming that checking and conversion policies are stateless and are
not supposed to define new public interfaces (so no need to inherit from
them) we still left with MI from storage and ownership policies.

Pros:
   a. Elegance and simplicity of design.
   b. Strict division on orthogonal policies, even though nothing prevent
you from parameterizing you own let say storage policy with cheching policy.
   c. Your comment here

Cons.
   a. Possible memory overhead caused by MI preventing some compilers to
perform efficient EBO.
   b. May have issues with impossibility to implement some practical
examples of smart_ptr, due to orthogonality of policies (do not have an
example, could be red herring)
   c. Your comment here

2. Chained inheritance: every policy has additional parameter ParentPolicy
from with it is inherited

Pros.
   a. Resolve issue 1.a.
   b. Chaining could be used to resolve some problems with orthogonal
policies (do not have an example, could be red herring)
   c. Your comment here

Cons.
   a. Less elegant then 1
   b. Does not allow to resolve all interpolicy communications issues since
provide only one way access.
   c. Will add additional template parameter to policies. It will have 2 bad
consequences: it may require partial specialization sometime instead of
explicit one; it may transform some policies that were implemented as
regular classes to templates, and that again may cause partial
specialization sometime
   d. Your comment here

3. Intermediate policies mixer: smart_ptr is parameterized and is inherited
from one template parameter, which in turn export all other policies.
We could provide predefined mixers that will 'mix' in Item 1 style or Item 2
style.

Pros.
   a. May resolve issue 1.a if chaining mixer is used.
   b. More flexible then 1 and 2
   c. Allow to resolve most interpolicy communications issues (I assume).
   c. Your comment here

Cons.
   a. Less elegant and more complex design then 1 or 2
   b. Too flexible that may cause policies incompatibilities. I.e. policy
intended to be used with MI mixer would not work with chaining mixer. That
may decrease policies reusability.
   c. Since many users would expect to reuse policies supplied with the
framework they will be bound to decision made by policies implementer ( or
we need to have all policies implemented in all styles).
   d. Your comment here

4. Coplien/Barton-Nackman idiom: smart_ptr is inherited from polices it
parameterized with, while all of them are parameterized with smart_ptr
itself.

Pros.
   a. Allow to resolve most interpolicy communications issues (I assume).
   b. Your comment here

Cons.
   a. The same memory overhead as with Item 1
   b. Less elegant and more complex design then 1.
   c. Your comment here

5. Partial containment: smart_ptr contain policies instances
Assuming that checking and conversion policies are stateless and does not
supposed to define a public interface and that ownership policy could be
stateless also we could make smart_ptr to *contain* instance of storage
policy (it will need to provide a public interface to it) and *inherit* from
ownership policy (another alternative is to use compressed_pair here).

Pros.
   a. Resolve issue 1.a.
   b. Your comment here

Cons.
   a. The same interpolicy communication issues as with Item 1
   b. Less elegant and more complex design then 1.
   c. Since smart_ptr will need to access storage policy instance through
public interface it may break encapsulation, since smart_ptr users will also
have an access to the same interface.
   d. Your comment here

6. Policy Adaptor idiom

Pros.
   a. May or may not have memory overhead of Item 1.
   b. Resolve most of the interpolicies communication issues (I am assume,
but I am not sure since never travel that road)
   b. Your comment here

Cons.
   a. Less elegant and more complex design then 1.
   b. Less policies reusability. Let say I wont to write my own ownership
policy. As Dave A. suggested I already have default_smart_ptr_policies. So
now I need to inherit from it to customize ownership part of policies. But
how could I use my new ownership policy with different checking policy?
   c. Your comment here

Regards,

Gennadiy