[boost] Re: intrusive_ptr / shared_ptr.

From: Ed Brey (brey_at_[hidden])
Date: 2002-07-19 08:52:07

"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.  This is similar to what shared_ptr does currently in a limited fashion.  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.

2. Expand shared_ptr's templatized type to provide compile-time checking for ODR violations.

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

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).  :-)