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