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

From: Boris Fomitchev (fbp_at_[hidden])
Date: 2000-01-05 21:13:31

Greg Colvin wrote:

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

Totally understand. I would point out, though, that synchronization is a
kind
of thing that has to be invasive (one could write synch_ptr wrapper around
shared_ptr using mutexes, but that would end up with extra overhead, as
atomic increment/decrement
is all shared prt needs, and this is a single instruction in most popular
architectures.
If you totally against parameterization, then synchronized primitives should
just be
parallel to non-synchronized, like there would be shared_ptr and
synchronized_shared_ptr
with same traits except thread safety.

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

This looks like being unevitable. It is being solved with member templates,
when SomethingElse is factored out as variable template parameter in the
method.

-Boris.