Re: [boost] Re: Re: intrusive_ptr / shared_ptr.

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-07-19 13:01:54

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, July 19, 2002 1:53 PM
Subject: Re: [boost] Re: Re: intrusive_ptr / shared_ptr.

> From: "Navi Singh" <singh_at_[hidden]>
> > > > > >  ptr<test1> t1(new test1);        // ptr is a shared_ptr.
> > > > > >  ptr<test2> t2(new test2);        // ptr is an intrusive ptr.
> > > > >
> > > > > You could do that, but why not simply restating the above as:
> > > > >
> > > > > shared_ptr<test1> t1(new test1);
> > > > > intrusive_ptr<test2> t2(new test2);
> > > > >
> > >
> > > I have never liked the kind of design where the same class template is
> > > "overloaded" to mean different things, depending on what is "best for
> the
> > > user." That's like... like... like making vector<T> not a vector for
> some
> > T!
> > >
> > > Let me speak on the user's behalf here: I am perfectly capable of
using
> > the
> > > appropriate pointer type, thank you very much.
> > >
> >
> > Peter,
> >
> > Are you saying that there are philosophical issues with the proposed
ptr?
> I
> > was thinking along the lines of having everyone in my group use the
> proposed
> > ptr, and have them decide while writing the classes, whether they want
ptr
> > to be intrusive or not.  If its a bad idea, I'd like to hear more about
> it.
>
> Not really. I don't want to incorporate the automatic selection into
> shared_ptr, but there is nothing wrong in writing and using your own type
> selector, if you really need to.
>
> > If there are no technical issues, could you provide some guidance as to
> what
> > I need to do to make this work. It would be even nicer if someone posted
a
> > complete implementation :)  I don't have enough expertise to make the
> > inclusive_ptr work :(
>
> The easiest way is to use a 'generator':
>
> template<class T> struct pointer_generator
> {
>     typedef typename mpl::if_c< is_convertible< T *, counted_base
*>::value,
> intrusive_ptr<T>, shared_ptr<T> >::type type;
> };
>
> (I'm not sure that I have the syntax right.)
>
> Its use would be:
>
> pointer_generator<test1>::type t1(new test1);
>
> Getting rid of the ::type would expand the implementation a bit:
>
> template<class T> class ptr: public pointer_generator<T>::type
> {
> // replicate all necessary constructors
> };
>
> The 'right way' is to use private inheritance and using declarations; it's
> also much more verbose.
>
Just a comment.
Although I'm not totally convinced yet that a unique smart_ptr<>
consolidating both intrusive/shared_ptr behavior will not behave under the
as_if rule (I'm still trying to decide if Ed or Peter is right on this one),
I do agree with Peter that a class with a varying semantic is a bad choice.
On the other hand, a type generator is usually allow to do that. Therefore,
a conservatory choice would be to use the generator explicitly: that is,
instead of writing ptr<T> all the time and let it decide what to do 'under
the hoods', use:

 typename pointer_generator<T>::type t ( make_smart_ptr( new T) ) ;

this way, you gain the flexibility of ptr<> but with further control of
what's going on.

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