[boost] Re: policy-based smart pointers are EVIL!

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-04-19 11:57:34

<DKl_at_[hidden]> wrote in message
news:904AA220ACB4D211A10600104B3E85C92A82C7_at_MAIL...
> > Andrei Alexandrescu wrote:
> > "Dietmar Kuehl" <dietmar_kuehl_at_[hidden]> wrote
> > >The problem with policy-based designs is that similar entities with a
> > similar intention become incompatible. For example, you cannot assign
> > a
> > smart pointer using an intrusive counter to a smart pointer using an
> > external counter (well, if you are really careful this may be even
> > workable but in general it is definitely not). That is, for the sake
> > of
> > interfaces you want to use just one style for an entity.<
> >
> > You don't want to assign a smart pointer using one ownership policy to
> > a smart pointer using a different, incompatible ownership policy.

> For internal implementation of services choice is a good thing such
> that it is possible to tune the strategy to the specific needs. When
> it comes to interfaces choice is evil!

How do you think to provide this implementation choice?  Also: Policies are
not the part of the interface. Polices names plus framework name form one
long class name (Given template typedefs you will be able to make them
short). Where ot not arbitrary class A is convertable to an arbitrary  class
B depends only on the present of appropriate constructors. In our case
appropriate constructors for policies, since framework will forward copying
work to them.

>
> That is, it is impossible to have just one smart pointer configuration
> applicable across all kinds of objects: For some an external counter is
> the right thing, for other an internal counter. However, with respect
> to the counter I would claim that this aspect depends entirely on the
> type: If one object of this type can use an intrusive counter, all
> other will be able to do so, too. The external counter is need for a
> complementary set of types. Of course, local needs may dicate different
> choices but these shall not leak to the component's interface.
>
> That is, different policies for smart pointer for different types are
> needed and something like the current 'boost::shared_ptr<T>' is not the
> right approach (because it tries to make the choice how the counter is
> maintained for all types). However, a highly parameterizable smart
> pointer is neither because it will cuase different users to make
> different choices although the resulting objects are supposed to
> interoperate seamlessly.

They will if you provide convertions. GEneral comments. I do not favor
components that are "too smart".
You will never be able to cover all the cases. For given type T there are a
lot of strategies to manage it and a lot of choises to do:
shareble/no-shareble, if sharable type of control; type of an access (allow
disallow direct access ), thread-safe or not  and so on. Most of them could
not be deduced only from type.

Gennadiy.