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

br

Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk