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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-01-04 02:04:15

"Jeremy Maitin-Shepard" <jbms_at_[hidden]> wrote in message
news:87wu88mdnv.fsf_at_jbms.ath.cx...
> "Thorsten Ottosen" <nesotto_at_[hidden]> writes:

[snip]
> > Good. The faq does not say why this is important, maybe you know why?
>
> By making smart pointers interchangeable with real pointers, it is not
> only easier to integrate them into existing code,

They a far from a drop-in replacement.

> but it is also easier
> to understand their semantics.

Good smart pointers will be used over and over again and the small
difference in semantics
that I propose can be learned very easily.

> Also, the pointer semantics are useful
> in many cases.  Finally, pointer semantics are suggested by referring to
> it as a smart pointer.

Not a bit. by calling it "smart" you don't think that you'll get a normal
pointer.

> > An in what cases will it not be solved with mutable?
>
> The address to which a const real pointer points cannot be changed.
> Similarly, the address to which a const shared_ptr points cannot be
> changed using reset.  By using mutable, all const safety is eliminated.

Perhaps, but so even more when a const member function changes the state of
a stored member.
It's really a paradox why people want to do that; but hey, I accept that you
wan't that.

> Similarly, const_cast is error prone.

a member function would solve this.

> As others have mentioned, there is already a perfectly good way of doing
> what you want, that is completely consistent with the workings of real
> pointers.  shared_ptr<T const>.

Again, this won't work. Try it.

> On the other hand, with your proposed
> semantics, error-prone techniques such as the use of const_cast are
> needed to obtain the current semantics/the semantics of real pointers.

See above.

> >> Const propagation only makes sense if there are deep copy semantics.
If
> >> there are not deep copy semantics, the smart pointer can simply be
> >> copied and the const is gone.
>
> > Sure, and you could add mutable or do a const_cast. That's fine. Those
> > are deliberate actions and the chance of someone doing something wrong
> > is minimal.
>
> It is an example of why your proposed semantics do not make sense in the
> context of the C++ type system.  The use of const_cast should be the
> only way to defeat constness in the type system.  Copy construction
> should not be.

So just prohibit construction from a const object.

> > [snip]
>
> >> Thus, const propagation could reasonably be supported by a policy in a
> >> policy smart pointer, but it is not suitable for shared_ptr.
>
> > What about scoped_ptr? Or scoped_array?
>
> What would be the purpose of this special behavior?  If you want a const
> pointee, you can cast the result of scoped_ptr::get().

This is too trouplesome.

> Neither
> scoped_ptr nor scoped_array was designed to have container semantics.

yet they own the stored pointer.

br

Thorsten