Boost logo

Boost :

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-09-04 18:54:11


From: David Abrahams <david.abrahams_at_[hidden]>
> From: "Greg Colvin" <gcolvin_at_[hidden]>
> ...
> > > > 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;

Which works until you decide that a different policy gives
you better performance, so you ship out a new DLL and try
to convince your customers that they have to recompile all
their applications.

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

Right. I want the main interface to be nearly as simple as it is
now, and put the work onto advanced users.

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

;->

And nobody even pays me to write C++.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk