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

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
> news:87wu88mdnv.fsf_at_jbms.ath.cx...
>> "Thorsten Ottosen" <nesotto_at_[hidden]> writes:

> [snip]

> 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?

> [snip]

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

> 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