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

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2004-01-04 01:27:32

"Thorsten Ottosen" <nesotto_at_[hidden]> writes:

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

> [snip]

>> The point is that shared_ptr is designed to work like a real pointer, as
>> far as constness.  You are proposing that it work in a different way.
>> Thus, with your proposed semantics, shared_ptr could not be used
>> interchangeably with a real pointer; special handling would be required
>> for shared_ptr.

> 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, but it is also easier
to understand their semantics.  Also, the pointer semantics are useful
in many cases.  Finally, pointer semantics are suggested by referring to
it as a smart 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.

Similarly, const_cast is error prone.

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

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

> [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().  Neither
scoped_ptr nor scoped_array was designed to have container semantics.
Once again, standard techniques can be used to obtain your desired
semantics using the current scoped_ptr and scoped_array, while
error-prone techniques such as the use of const_cast would be needed to
obtain the current semantics from a scoped_ptr with your proposed
semantics.

Once again, I will say that const propagation is a reasonable policy to
accompany a deep copy policy in a policy-based smart pointer, but it is
not a suitable policy for the existing smart pointers with shallow-copy
or no-copy semantics.

-- 
Jeremy Maitin-Shepard