[boost] Re: Smart Pointers - (many) thanks and (some)questions

From: Greg Colvin (gcolvin_at_[hidden])
Date: 1999-12-30 16:53:30

From: Beman Dawes <beman_at_[hidden]>
> At 12:45 PM 12/28/99 -0800, Boris Fomitchev wrote:
> 
> >I do believe good strategy is to add default bool template argument
> :
> >
> >template < class T, bool Synchronized = false>
> >class shared_ptr
> >.....
> 
> 
> During the initial boost discussions of shared_ptr<>, we agonized
> over whether or not to parameterize the direct vs indirect
> implementation techniques.  We decided against parameterization
> because it is confusing to users.
> 
> Parameterizing non-invasive vs invasive implementations has also been
> discussed.  There was a recent thread about parameterizing the method
> of deletion (which may still fly if it can be worked out).  There is
> also the smart_ptr flavor which doesn't allow the pointer to ever be
> null. And now "Synchronized."
> 
> It isn't that these aren't valuable techniques; they all are.  But
> trying to load them all into a single smart pointer would just create
> a monster.
> 
> So don't take it personally; we are being deliberately conservative
> with smart pointers.

There is another reason I am resisting adding template parameters
to shared_ptr, which is that shared_ptr<T,Something> is a 
different type than shared_ptr<T,SomethingElse>.  For some designs
this can be a problem.

How so?

Consider:

   class Widget {
   public:
      static shared_ptr<Widget> Make(. . .);
      . . .      
      virtual . . . =0;
      . . .      
   };

We have a Widget interface with a factory function for making 
various types of Widgets, and we return a shared_ptr<Widget> to 
facilitate the safe management of Widget lifetimes.

Now let's suppose we need to change our way of allocating and
deallocating widgets, and that we have parameterized shared_ptr
accordingly.  So we would need to change our interface
      static shared_ptr<Widget,WidgetNuker> New(. . .);
and would also need to recompile all the Widget users, which
defeats one major purpose for using interaces and factory
functions in the first place.

Now let's suppose we need to change some aspect of how we handle
widgets, and that we have parameterized shared_ptr accordingly.
So we would need to change our factory function
      static shared_ptr<Widget,SomethingElse> Make(. . .);
and we would also need to recompile all the Widget users, which
defeats one major purpose for using interaces and factory
functions in the first place, which is to minimize recompilation
when implementation details change.

I am thinking that some details of the shared_ptr implementation,
such as the deallocation function, should be abstracted into a
class with virtual functions, an instance of which can be passed
into the shared_ptr constructor, and the rest handled either by
derivation from shared_ptr (for adding or hiding operations) or
conditional compilation (for thread safety on various systems).

------------------------------------------------------------------
Greg Colvin         greg_at_[hidden]          gcolvin_at_[hidden]