Re: [boost] shared_ptr evolution

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-07-26 12:31:29

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.

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

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.