From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-01-04 00:11:24
"Jeremy Maitin-Shepard" <jbms_at_[hidden]> wrote in message
> "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
> 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?
An in what cases will it not be solved with mutable?
> 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
and the chance of someone doing something wrong is minimal.
> 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.
What about scoped_ptr? Or scoped_array?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk