Boost logo

Boost :

From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2003-01-28 12:38:28


At 09:37 AM 1/28/2003, Andrei Alexandrescu wrote:
>"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.
>
>[...]
>> 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 don't believe that, whoever said it. I do think shared_ptr
can cover a large enough set of uses to be well worth having.

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

Right. But we don't have that language yet.


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