From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-07-19 13:01:54
----- Original Message -----
From: "Peter Dimov" <pdimov_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
> > > user." That's like... like... like making vector<T> not a vector for
> > T!
> > >
> > > Let me speak on the user's behalf here: I am perfectly capable of
> > the
> > > appropriate pointer type, thank you very much.
> > >
> > Peter,
> > Are you saying that there are philosophical issues with the proposed
> > was thinking along the lines of having everyone in my group use the
> > ptr, and have them decide while writing the classes, whether they want
> > to be intrusive or not. If its a bad idea, I'd like to hear more about
> 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
> > I need to do to make this work. It would be even nicer if someone posted
> > 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk