[boost] Re: Interest in smart pointer with value semantics?

From: David B. Held (dheld_at_[hidden])
Date: 2004-01-02 23:13:13

"Daniel Wallin" <dalwan01_at_[hidden]> wrote in message
news:3FF562C5.5050403_at_student.umu.se...
> [...]
> Really? I'm assuming you mean that it could be spelled that way if
> deep_copy was rewritten ... to support capturing of the pointee type
> at the time of construction.

We don't need to rewrite it.  We just need to create another policy. ;)

> But even then smart_ptr<> is lacking the:
>
>    const_pointer_type operator->() const
>    const_reference_type operator*() const
>    .. and maybe a templated reset().
>
> needed to propagate constness.

Well, there was much debate about whether smart pointers should
propagate constness or not.  The consensus was that shared_ptr<>
should not, due to the rationale given in its documentation:

    Q. Why is operator->() const, but its return value is a non-
    const pointer to the element type?

    A. Shallow copy pointers, including raw pointers, typically don't
    propagate constness. It makes little sense for them to do so,
    as you can always obtain a non-const pointer from a const one
    and then proceed to modify the object through it.shared_ptr is
    "as close to raw pointers as possible but no closer".

But then, we aren't talking about a shallow copy pointer, so perhaps
smart_ptr should support const propagation for certain policies.

> But then, const_pointer_type and const_reference_type comes
> from the storage policy so we'd need one of those too.

Which is actually a good thing.  That way, you can write one type of
storage policy which propagates constness, and another which
doesn't.

> And the storage policy also needs to capture the type to
> properly delete the pointee.
>
> So we end up with;
>
>    smart_ptr<
>        T
>      , deep_copy
>      , const_propagating_storage
>    >

Doesn't look so bad to me (except maybe a little more verbose
than some people would like).

> Unfortunatly both the storage and ownership policies need to
> capture the type of the pointee, meaning they both need to store
> a function pointer.

Well, this forced me to dig through shared_ptr<> some more, and
now I understand what the default checked_deleter<> is all about.
However, it seems to me that more deleters are being saved than
is strictly necessary.

> So we'd end up with a smart pointer that is much larger than
> needed.

Well, it depends entirely upon how the deleter is implemented.
While thinking about solutions to this problem, I considered
whether a static map/associative vector/hash map of deleters
might be more efficient overall.  After all, there will probably be
many more pointers than there will be deleter types.  I guess it
comes down to a tradeoff in creation speed vs. size.  And, of
course, that could probably be controlled by a policy. ;)

Anyway, I'm cooking up some ideas for how it could work, but I
don't have the time to flesh them out right now, so hopefully, I'll
have something more concrete in a week or so.

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003