Re: [boost] Re: Deadline for the Standard Library TechnicalReport

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-01-28 12:34:31

From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> news:00b201c2c6da$16c22e70$1d00a8c0_at_pdimov2...
> > From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
> > [...]
> > >
> > > It should be noted that the constructor taking a custom deleter has
many
> > > implementation efficiency consequences that are not mentioned in the
> > > Standards proposal nor in the shared_ptr doc. My feeling is that the
> > > documentation at
> > > http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1397.html and at
> > > http://www.boost.org/libs/smart_ptr/shared_ptr.htm is coy about
> mentioning
> > > that the added constructor requires quite some more overhead under the
> > > covers, including runtime polymorpshim, virtual calls, extra
> allocations,
> > > all those good things.
> >
> > The runtime polymorphism/virtual call issue is not exclusively mandated
by
> > the two-argument constructor. It is necessary to capture the
deallocation
> > information at construction time in order to support incomplete classes,
> > EXE/DLL heap mismatch, and shared_ptr<T>'s ability to call the right
> > destructor regardless of T.
>
> I understand that. I also know not all people would need all that.

Absolutely. A single pointer can't answer every problem. But my point was
that given the above, custom deleters are essentially free.

> > I really don't understand why you consider policy-based smart pointers
and
> > the current shared_ptr enemies, when in my opinion they perfectly
> complement
> > each other. But I've grown tired of asking.
>
> I guess I started feeling that way when I've been told that shared_ptr is
> everything everyone will ever need, so there's no need for policy-based
> smart pointers :o).

_I_ never stated that. ;-)

> In a language with template typedefs, there would be no complementarity -
> shared_ptr will be but one point in the design space allowed by smart_ptr.

Again, this depends on the design goals that you have set for smart_ptr. Not
stretching smart_ptr to cover shared_ptr may produce a better design. Or it
may not. But I don't see shared_ptr as a mandatory point in the design
space.

The two designs have different basic principles. shared_ptr answers the
question "if you had to design a smart pointer that is only parameterized on
the value type, and its behavior does not depend on the parameter (i.e. you
can state Requires/Postconditions/Throws/Exception Safety independently of
the parameter), what would the result be?"

smart_ptr<> comes from the opposite end. It is not constrained by a "single
type", and uses this fact in its advantage. It is a feature of smart_ptr<>
that different pointers have different types. It is a feature of shared_ptr
that different pointers have single type.

Given a smart_ptr<>, shared_ptr's FAQ would say

Q. I need feature X, why doesn't shared_ptr do what I need?
A. smart_ptr.

By the way, the current typedef template proposal prohibits deduction; this
makes it less attractive for creating subpointers.