Re: [boost] Re: Re: Deadline for the Standard Library Technical Report

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-01-28 09:32:29

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.

There are no extra allocations associated with the two-argument constructor.
Many deallocators are empty classes, and it's possible to use the empty base
optimization (compressed_pair) so that they add no size overhead. The
current implementation doesn't use this optimization, though.

> Ah, there's also the compulsive locking on
> multithreaded builds (whether the user wants it or not).

Yes, this is a very good argument in favor of policy-based smart pointers.
You can only go so far given the "one type" constraint.

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.