Re: [boost] shared_ptr evolution

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-07-26 13:24:17

At 01:31 PM 7/26/2001, Greg Colvin wrote:
 >From: Beman Dawes <bdawes_at_[hidden]>
 >> At 09:09 AM 7/26/2001, Peter Dimov wrote:
 >>
 >>  >From: "Philip Nash" <philip.nash_at_[hidden]>
 >>  >> Agreed. Sorry, I wasn't suggesting that the finalizer function be
 >> dropped
 >>  >> from your proposal,
 >>  >
 >>  >There's nothing wrong with suggesting that. I am not entirely 
convinced
 >>  >that
 >>  >adding this finalizer support to shared_ptr is a good idea. I simply
 >>  >demonstrated that it can be done; this doesn't mean that it must be
 >done.
 >>
 >> I think that is a really important point.  There are lots of advantages 
to
 >
 >> a small, very stable, shared_ptr.  I really think that many of the
 >possible
 >> "improvements" should be explored in the context of a completely new
 >> design,  along the lines of Andrei Alexandrescu's smart pointer policy
 >> classes.
 >
 >I agree.  But that new design will be a long time coming, so I am
 >looking for the smallest set of improvements to shared_ptr that
 >will satisfy the most complaints, soon.  The lack of a dynamic
 >cast facility is one long-standing complaint, and Peter has a fix
 >for that.  The question is whether this is a good time to fix
 >some other complaints, and if so which ones.

That makes sense.

 >A large number of complaints come down to not being able to use
 >any memory management besides new/delete.  This makes shared_ptr
 >useless for COM-style cross-dll use, for memory obtained from
 >C libraries and system calls, for objects obtained from the
 >standard and custom allocators, and so on.  Being able to specify
 >a finalizer function is the best way I can see to solve this
 >problem.  I especially like that in Peter's solution the choice of
 >finalizer does not affect the type of the shared pointer.  This
 >makes it easy for functions that create objects and return a
 >shared_ptr to hide their memory management implementation, and to
 >change it without forcing a recompilation of their callers.  So I
 >am very much in favor of accepting Peter's shared_count.

A strong endorsement.  I'll try to look at it in the next day or so.

 >A second set of complaints come down to wanting the shared_ptr
 >interface with a different implementation, such as intrusive
 >counts, linked lists, or garbage collection.  This can be handled
 >now by cutting and pasting.  It could also be handled with a
 >parameterized base class like this
 >   template<typename T,class Base=shared_ptr_base<T> >
 >   struct shared_ptr : Base
 >or even like this
 >   template <
 >      typename T,
 >      template<typename U> class Base=shared_ptr_base >
 >   struct shared_ptr : Base<T>
 >I'm less sure whether this is worth the trouble, as I have had a
 >hard time designing a good base class. But I remain open to
 >suggestions, as having such a base class would make it easier
 >for others to provide alternative implementations.

I'm not very enthusiastic about it.

 >A third set of complaints is the lack of thread safety, which I
 >suspect we should postpone until Boost::threads is ready.  But
 >perhaps Peter's shared_count class could be exposed as a default
 >parameter to the shared_ptr template, so that those needing
 >thread safety now can provide their own implementations.  Of
 >course if we go with the parameterized base class then those
 >needing more thread safety could do so by providing their own
 >base class.

Boost.Threads is very close to being ready for review.  Let's wait until it 
is finished, then revisit thread safety.

--Beman