Re: [boost] Smart pointer poll

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-05-15 07:02:10

From: "Stewart, Robert" <stewart_at_[hidden]>
>
> > 3b. Should there be a single smart pointer type that is
> > specifically
> > designed to cover a variety of common situations without
> > requiring any user
> > intervention or customization?
>
> If there isn't, many users won't use them. However, that doesn't mean that
> it can't be a type with all but one template parameter defaulted.

Yes, of course. It _can_ be a template with defaulted parameters. The
question is: _must_ it be a template with defaulted parameters? Why is a
template with defaulted parameters better?

> There's
> good precedent in Standard C++ for this: char_traits and allocators are
> rarely specified. Thus, defaulting some number of template parameters
won't
> put off today's C++ programmer.

The char_traits/allocator precedent is a very good example, and you can draw
all sorts of conclusions from it. ;-)

> > 3d. If it is, which is the best way to provide a smart pointer
> > that meets
> > that specification?
> >
> > A) shared_ptr<T>, implementation details unspecified
>
> There's nothing wrong with that, that I can see. That can even be a
template
> typedef specializing the framework class template.

I see nothing wrong with it, either.

> > B) shared_ptr<T>, implementation required to be derived from a
> > general
> > pointer framework
>
> I don't see why you would need to require this implementation.

The alternative is included because people have expressed this opinion
during the debate. (Beman's summary seems to imply that some LWG members
feel the same way.) I presume that their reasoning is: if the C++ standard
library includes a smart pointer framework, then the other standard smart
pointers should be derived from the framework as a proof of concept.

I don't buy the argument but I understand it.

> > I'd rather see a (concise) answer to the following questions
> > instead:
> >
> > 1a. Why is a smart pointer framework a good thing?
>
> Yes. We already know that customized smart pointers are not uncommon. If a
> framework can make those customized smart pointers easy, if not trivial,
to
> implement, then it is worthwhile. The alternative is for customized smart
> pointer developers to look at and copy existing practice to create new
ones.
> Using the framework means that bug fixes to the framework automatically
fix
> all smart pointers based upon it.

This doesn't actually apply to the standard library. Fixing bugs in the
standard library (design) takes time. A standard framework must be bug free.

> If each smart pointer is handcrafted, then
> each must be checked for the problem and each must be corrected, if
> necessary.
>
> > 1b. What are the design goals of the framework?
>
> - Factor out common code, with the attendant maintenance benefit
> - Standardize interface (which could be specified in the standard without
a
> framework, of course)
> - Simplify creating specialized, custom smart pointers

Looks almost obvious; that's probably the reason that nobody cared to
answer. :-) Implementing smart pointers is a common task (t/f?); these smart
pointers share common code (t/f? which code?); therefore, a standard
framework can help (t/f? is implementing a policy easier than implementing a
pointer using editor inheritance?).

Note how these design goals say nothing about auto_ptr and shared_ptr. Do
they fit the "common code" pattern? They might, but this should be carefully
thought out and not just accepted as an axiom.

> > 1c. What user problems does this framework address?
>
> Which user?

The user of the framework, not the user of the user of the framework. :-)