[boost] Re: Re: intrusive_ptr / shared_ptr.

From: Ed Brey (brey_at_[hidden])
Date: 2002-07-19 11:00:45

"Peter Dimov" <pdimov_at_[hidden]> wrote in message news:004101c22f33$df5432f0$1d00a8c0_at_pdimov2...
> 
> 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.

I'm not arguing about the user's capabilities.  I'm looking for an opportunity to perform an automatic optimization.  For example, no one complains when std::copy figures out that it is working with PODs and does a memcpy silently instead.  The user could have type memcpy himself, but he's even more thankful to not have to.

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

Let me try to make the similarity more obvious.  I am comparing two shared_ptrs here, the current design, which I'll call shared_ptr1, and a proposed one which has the three features I mentioned, which I'll call shared_ptr2.  Note that shared_ptr2 incorporates changes to the shared_ptr class, plus other definitions, such as counted_base.

Shared_ptr1 has a property in that it doesn't put the count on the heap if it is embedded in the managed object.  Shared_ptr2 is similiar in this regard.  The two are similiar in that this property amounts to an optimization over a shared pointer that always allocates the count itself (and yes, wouldn't allow attaching to objects that manage their own count).  Shared_ptr1 is more limited than shared_ptr2, however, since use the object's count is not used if the object is const.  Also, shared_ptr1 is more limited in that it does not perform the optimization of eliding the counter pointer when unnecessary.

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

I see what you are getting at, assuming your talking about the requirement that T be complete.  Is there no way for the decision on whether the compiler elides the couter pointer to be deferred until T is defined?

> > 3. Provide equally convenient optimization of shared_ptr<T const> as
> exists for shared_ptr<T>.
> 
> I don't understand this point.

My meaning is that if T holds its own count, that count should be used regardless of whether <T const> or <T> is the template parameter.

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

A single smart pointer class that provides many types based on selection of orthogonal features is fine.  The proliferation to avoid is independent smart pointers that happen to have a large overlap in functionality.