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
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
is all shared prt needs, and this is a single instruction in most popular
If you totally against parameterization, then synchronized primitives should
parallel to non-synchronized, like there would be shared_ptr and
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk