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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-01-03 00:08:43

"David B. Held" <dheld_at_[hidden]> wrote in message
news:bt5fg4$ca3$1_at_sea.gmane.org...
> "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".

I still don't understand this. The "It majes little sense..." argument is
*totally*
bogus. You can always be malicious in C++ if you want. Having to
write shared_ptr<Foo> = foo_ptr_; is warning enough.

Consider then my argument that classes should not provide const overloads:

"Classes, including built-in types, are typically not const correct. It
makes little sense
for them to do so as you can always cast away the constness and then proceed
to modify the
object."

Having propagation of constness makes a lot of sense and would certainly
make the smart pointers a lot smarter.

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

what about

smart_ptr< const T, deep_copy > ?

br

Thorsten