Boost logo

Boost :

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
deliberate actions
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, gregod at, cpdaniel at, john at