Re: [boost] Re: Re: Traits-based design and ODR

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

From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
> 1. Shared pointers allow you to change at runtime the function with
> which the pointer is destroyed.
>
> The main reason, it's been said, is to allow library writers to change
> that function without having to change the binary layout of the code.
>
> This is indeed the case with dynamically-linked libraries. However, if
> the library is statically linked, the following construct offers the
> same capabilities, without any overhead:
>
> // Before
> shared_ptr<FILE> sp(pFile, fclose);
> // After
> shared_ptr<FILE, &fclose> sp(pFile);

Nice. This still keeps the type of shared_ptr fixed.

But it doesn't solve the problem in general. Here's a real world example:

class drag_handler
{
// abstract
};

class mouse_handler
{
public:

    virtual shared_ptr<drag_handler> beginDrag() = 0;
};

Different mouse_handlers (in the same program) allocate their drag_handlers
via different mechanisms.

Derived to Base conversions also present a problem with the 'after' design
AFAICS.

> 2. shared_ptr has significant size and speed overhead for COM and
> CORBA-style smart pointers

shared_ptr is not intended to work with COM. shared_ptr solves some specific
problems; it is not intended to be the ultimate smart pointer. It does not,
repeat not, compete with Loki::SmartPtr or with any other smart pointer.

> 3. I believe that having a "default smart pointer type" is not such a
> good idea.

You aren't part of the target audience. :-) People often need a default
smart pointer, or a default container. If it works adequately, it stays. If
it doesn't, it gets replaced. Replacement actually happens in few cases
unless the programmer adopts a religious - not pragmatic - approach.

Whether that default is called shared_ptr<T> or smart_ptr<T> or
ptr<T>::shared doesn't matter.

shared_ptr tries to be that default; one of its design goals is to "just
work and do the right thing" in a variety of nontrivial situations
(incomplete types; object allocated on DLL heap but the last shared_ptr
destroyed by the EXE; derived to base, T to T const, T to void conversions;
pointers to unrelated types that share ownership; thread safety; and so on.)
True, this has a cost. We have tried to keep that cost at a minimum.

--
I am left with the impression that this whole discussion is full of
misunderstandings. You are trying to justify the existence of Loki::SmartPtr
by attacking shared_ptr (does it work with COM? does everyone need runtime
polymorphism? no, and no, in that order.) But shared_ptr is not a threat,
and nobody questions the usefulness of Loki::SmartPtr. I wonder how we got
to this point.