From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-09-04 12:30:46
----- Original Message -----
From: "Greg Colvin" <gcolvin_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
> > > > 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
> > It is a relatively simple class, and should remain so.
> > > What I am trying to do is pull together the discussions and
> > > code and feature requests built up over the years into a new version
> > > 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 ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk