From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2004-01-04 03:16:17
"Thorsten Ottosen" <nesotto_at_[hidden]> writes:
> "Jeremy Maitin-Shepard" <jbms_at_[hidden]> wrote in message
>> "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
> 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.
The stored member is a memory address. The state of that stored state
is not being changed by a non-const member function. No paradox. Only
if there are deep copy semantics is it reasonable to think of the
object that contains the pointer also containing the pointee.
>> Similarly, const_cast is error prone.
> a member function would solve this.
What exactly are you referring to?
There already are member functions for this purpose -- they are called
get(), operator->(), and operator *(). If you call them something
else, it would indeed be ``too troublesome.''
>> 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.
I have tried it, and it does work. What doesn't work about it for you?
>> 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.
Once again, we lose functionality or have to resort to const_cast in
order to have your deep-copy semantics.
>> > [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.
Why is that troublesome?
>> Neither scoped_ptr nor scoped_array was designed to have container
> yet they own the stored pointer.
Well, it is less of a problem to have your semantics with scoped_ptr or
scoped_array because there is never any need to have a scoped_ptr const
&. However, then the semantics would be unnecessarily different from
those of shared_ptr.
-- Jeremy Maitin-Shepard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk