Re: [boost] Re: intrusive_ptr / shared_ptr.

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-07-19 09:52:14

From: "Ed Brey" <brey_at_[hidden]>
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:00a501c22f15$b48ec7b0$1d00a8c0_at_pdimov2...
> > >
> > >  As a rule, everyone will use a ptr template (defined later in this
post).
> > >  The ptr template will either be a shared_ptr or an intrusive_ptr
template
> > >  based on whether the class in consideration derives from counted_base
or
> > >  not.
> > >
> > >  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);
> >
> > The comments are no longer necessary. :-)
>
> I don't think that the intent of the example was to imply that actual user
code would have the comments.  The comments are useful for discussing the
example, but the true power in the example is the abstraction, the fact that
the user just uses "ptr" and it works optimally.
<

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.

> This is similar to what shared_ptr does currently in a limited fashion.

No, this is not similar in any way to what shared_ptr currently does.
shared_ptr<T> behaves consistently for any T.

> To realize the full potential of the abstraction, the following
implementation details are needed for shared_ptr:
>
> 1. Elide shared_ptr's counter pointer when addref exists for T.

This is not an implementation detail. It affects the interface.

> 3. Provide equally convenient optimization of shared_ptr<T const> as
exists for shared_ptr<T>.

I don't understand this point.

> Given these improvements, the shared_ptr would become the ptr of the above
example, and user's wouldn't need to know about or deal with intrusive_ptr
as a separate entity. This would be a boon to meeting the ideals of the
international SPPR treaty (Smart Pointer Proliferation Reduction).  :-)
<

The current trend in smart pointer development is to multiply, not reduce,
the smart pointer types by using combinatorial techniques. :-)