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

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2004-01-03 23:41:23

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

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

> [snip]

>> To get the const behavior of "T * const", i.e. const pointer,
>> use "shared_ptr<T> const" or "const shared_ptr<T>".
>> 
>> For generic programming purposes, shared_ptr<T> does in fact work
>> equivalently to boost::add_const<T>::type.  With your proposed change,
>> however, it would not.

Note: I meant add_pointer, not add_const.

> Is this used anywhere? If so, could there be work-arounds?
> This is really a cruial question. I would like to see your reply to
> all the other concerns, I mentioned earlier.

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.

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.

shared_ptr<T> const p1;

// With your proposed semantics, typeof(*p1) == T const

shared_ptr<T> p2(p1);

// typeof(*p2) == T

Thus, const propagation could reasonably be supported by a policy in a
policy smart pointer, but it is not suitable for shared_ptr.

-- 
Jeremy Maitin-Shepard