Re: [boost] On shared_xxx

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-09-04 12:30:46

----- Original Message -----
From: "Greg Colvin" <gcolvin_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, September 04, 2001 11:41 AM
Subject: Re: [boost] On shared_xxx

> From: David Abrahams <david.abrahams_at_[hidden]>
> > From: "Greg Colvin" <gcolvin_at_[hidden]>
> >
> > > > Taking a step back, we can come up with any number of designs, but
shouldn't
> > > > we talk about what the designs should accomplish first?
> > >
> > > We have been, but further discussion is welcome.
> > >
> > > What I'm not trying to accomplish is to parameterize shared_ptr to
> > > generate a large family of related classes.  That is a bigger project
> > > that should probably start fresh, and which will indeed require a
> > > clear delineation of a family of Pointer concepts.
> >
> > Agreed. That's what I think we should do. I don't think that mutating
> > shared_ptr a little bit just to satisfy one person's needs is the way to
go.
> > It is a relatively simple class, and should remain so.
> >
> > > What I am trying to do is pull together the discussions and
experimental
> > > code and feature requests built up over the years into a new version
of
> > > shared_ptr (and shared_array).  The desiderata for me are:
> > >
> > > 1) Shared_ptr remains one class, with one interface and one semantics.
> > >    Libraries should be able to use shared_ptr as a common means of
> > >    communication without needing to templatize their interfaces by
> > >    (smart) pointer type.
> >
> > I don't understand the 2nd sentence above.
>
> For a policy-based class like
>
>     template<typename T, class Policy> class shared_ptr;
>
> every choice of Policy creates a different class.  So you can't write
> interfaces that simply return or accept shared_ptr<T>
>
>     void MyBase::GimmeOne(shared_ptr<MyBase>);
>
> but have to either templatize
>
>     template<class Policy>
>     void MyBase::GimmeOne(shared_ptr<MyBase,Policy>);
>
> or choose in advance which Policy you will support.  For many programs
> this is no big deal, but for others it is.

I agree in principle, though as with everything in computer science, the
problem can be solved with an extra level of indirection:

  typedef shared_ptr<MyBase,Policy> MyBase_handle;

Anyway, if you think the convenience of avoiding those typedefs is important
(and I agree that in some domains it may be), then I think the simple
shared_ptr we have now is the tool for those clients.

> However, if you templatize the constructor, e.g.
>
>     template<class Policy> shared_ptr(T*);
>
> then choosing different policies does not change the type of shared_ptr.
>
> So the space I am exploring is the range of variations that can be
> supported in this way, and how simple can the interface be.

I think that if you want to do something fancy, you should be willing to
bear some slight syntactic overhead. I would make that tradeoff in favor of
not paying for what I don't use.

Anyway, maybe I'll float a design past the boost membership when I get done
with all the other things I'm doing ;-)

-Dave