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

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-04-19 13:56:21

"Fernando Cacciola" <fcacciola_at_[hidden]> wrote in message
news:a9pnih$1jm$1_at_main.gmane.org...
>
> "Gennadiy Rozental" <rogeeff_at_[hidden]> wrote in message
> news:a9pjah$oog$1_at_main.gmane.org...
> >
> > "Fernando Cacciola" <fcacciola_at_[hidden]> wrote in message
> > news:a9pfv7$cb7$1_at_main.gmane.org...
> > > Just my 2 cents...
> > >
> >

[...]

> > >
> > > template<class APtr>
> > > class Processor
> > > {
> > >   Processor ( APtr const& obj ) : m_obj(obj) {}
> > >   ...
> > >   APtr m_obj ;
> > > } ;
> > >
> > > These, however, intoduces a much higher engineering complexity to the
> > > system, because we have changed a non-template class to a template
class
> > > only because the smart_ptr is overparametrized (from the pov of the
user
> > of
> > > A who just wants to keep it alive).
> >
> > No. I disagree. Real problem here you want to reuse you Processor
> facility,
> > but do not know storage type. There as usual two choises runtime
> > polimorphizm - which I hardly believe you can accept, or compile-time
one
> > with we usually express in form of template parameters. And FWIW it does
> not
> > "intoduces a much higher engineering complexity".
> >
> But it does. Remember that Processor IS NOT A TEMPLATE class, and turing a
> non-template class into a template class *is* a very complex enginnering
> change. For the simplest of the reasons, if you change the implemention of
a
> template class you need to recompile the world because exporting templates
> is not currently available.

Do you know compile-time based solution that does not have this issue?

>
>
> > >
> > > Scenario 2:
> > >
> > > It is quite common to specialize certain things -such as predicates-
on
> a
> > > smart_ptr<>. This is in order to allow certain expressions to be
applied
> > > indistinctely to bare and smart pointers.
> > > For example, the boost shared-ptr declares:
> > >
> > > // get_pointer() enables boost::mem_fn to recognize shared_ptr
> > > template<typename T> inline T * get_pointer(shared_ptr<T> const & p) ;
> > >
> > > This is used -as the comment says- inside mem_fn which allows a very
> > > powerful usage of mem_fn.
> > >
> > > If shared_ptr were intrusively policy-based, this wouldn't be feasible
> > > becuase mem_fn couldn't know about the smart pointer policies.
> >
> > Why? Can't you write another predicate like this:
> >
> > template<typename StoragePolicy,...> inline StoragePolicy::pointer_type
> > get_pointer(smart_ptr<....> const & p) ;
> >
> mem_fn doesn't know about the different policies introduced in the
complete
> type it sees. So this would only work as long as there is one get_pointer
> specialization for each of the possible policy combinations.

Why? Here now mem_fn is using get_pointer:
    template<class U> R const & call(U & u, void const *) const
    {
        return (get_pointer(u)->*f_);
    }

Given my definition of get_pointer for smart_ptr. It does not need to know
anything about policies of smart_ptr. So the same as  with current
shared_ptr we need to write get_pointer once.

> > > Dietmar already shown -and I totally agree- that most of the smart ptr
> > > policies are usually type dependent, so they perfectly call for
external
> > > policies. (BTW, the sketch made by Doug seems very reasonable).
> >
> > I disagree here. What is type dependent? Specifically?
> >
> The count strategy (intrusive (either COM based or else) or external)

See my other post regarding all possible Ownership strategies for the same
type T

> The deallocation strategy is most of the times type-dependent.

This is also is not obvios. In some case I want delete pointrs of type T, in
other cases want to return them in some pool. Or do one or the othe depends
on some logic.

> These, along with the threading policy, are IMO the three most practical
> strategic choices for a *general* smart pointer.

How could you choose proper threading policy by given type T?

> And again... we are not against policy-based designs.. we are just trying
to
> figure out different ways to specify the policies; in search of one that
> doesn't clutter the interface that a user would like to use.

And again, I do not concider Polcies Names part of the interface, but rather
part of class name, fixed in any given application of the framework.

>
> --
> Fernando Cacciola
> Sierra s.r.l.
> fcacciola_at_[hidden]
> www.gosierra.com

Gennadiy.