Re: [boost] Smart pointer poll

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-05-06 06:30:42

From: "Dietmar Kuehl" <dietmar_kuehl_at_[hidden]>
> > A) shared_ptr<T>, implementation details unspecified
>
>
> Note, that this is only option in this list allowing type specific
> reconfiguration of the semantics! This is, however, not a problem with
> the other options just with the list of options :-)

I have two (new) arguments against the "morphing" shared_ptr controlled by
traits, one philosophical and one technical.

1. My idea of "appropriate" use of traits is to use them to specify type
properties, and not type-specific behavior, if possible. That is, the
Effects clause of any function shouldn't be affected by type traits; only
the performance. For example, using has_trivial_destructor<> in std::vector
is quite appropriate since the interface doesn't change. I think that
policy-based designs (or type generators) where one specifies behavior
explicitly, are better.

2. Let's assume that shared_ptr<A> uses pointer management strategy A, and
shared_ptr<B> uses strategy B. Consider:

struct C: public A, public B {};

shared_ptr<C> pc(new C);
shared_ptr<A> pa(pc);
shared_ptr<B> pb(pc);

pa and pb obviously share ownership; they can't use different strategies. So
you have to disallow at least one of the conversions above, making
shared_ptr (much) less flexible.