Re: [boost] Policy-based smart pointers revisisted

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-01-18 09:33:55

From: "Terje Slettebø" <tslettebo_at_[hidden]>
> >From: "David Abrahams" <dave_at_[hidden]>
> >
> > Please don't take this to mean I'm against a
> > policy-based smart pointer; quite the opposite.  I've
> > said all along it would be great to have one in boost.
> > I've even wished I had an appropriate occasionally.

Yep.

> > I just don't want to trivialize what I perceive to be
> > valid concerns, either.  Understanding the costs of
> > complexity should be as important to the designer of
> > policy-based classes as to everyone else, if not more
> > so.
>
> I understand the concern. For one thing, we don't have template typedefs,
> yet, although me may get a similar effect (if not the same type) with
e.g.:
>
> template<class T>
> struct shared_ptr : smart_ptr<T, policies...> {};

Not quite.

It is not simply declaration complexity that Dave's talking about - it can
be avoided by making smart_ptr<T> be shared_ptr<T> by using default
parameters. It is semantic complexity. shared_ptr is fairly deep by itself
(and getting the specification and the tests to a state that can be
considered adequate wasn't easy.)

If you make shared_ptr a point in smart_ptr<>'s design space, this
automatically means that smart_ptr is _at least as complex_ as shared_ptr to
teach, specify, test.

Whether smart_ptr should be made to encompass all of the shared_ptr's
functionality (verbatim) is another matter. A policy-based smart pointer has
different design goals, and it might be better to cover (an useful subset
of) the functionality of shared_ptr without copying its interface as is,
using the strengths of the medium, so to speak.

Now to return the suggestion above.

What are the primary strengths of a policy based smart pointer?

1. It allows users to create their own custom smart pointers.
2. It allows users to globally switch to another smart pointer type by
changing a typedef:

typedef counted_policy default_ownership;

// project uses smart_ptr<T, default_ownership, ...> throughout

3. It allows users to write generic functions that can take any smart
pointer.

(1) and (3) aren't affected by convenience wrappers, and (2) is made more
difficult if the shared_ptr<> pictured above is used in the project.

For completeness, there is also

4. Depending on the PBSP design, it might allow users to mix and match smart
pointers of different types.