Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-01-04 02:04:15


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

[snip]
> > 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,

They a far from a drop-in replacement.

> but it is also easier
> to understand their semantics.

Good smart pointers will be used over and over again and the small
difference in semantics
that I propose can be learned very easily.

> Also, the pointer semantics are useful
> in many cases. Finally, pointer semantics are suggested by referring to
> it as a smart pointer.

Not a bit. by calling it "smart" you don't think that you'll get a normal
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.

Perhaps, but so even more when a const member function changes the state of
a stored member.
It's really a paradox why people want to do that; but hey, I accept that you
wan't that.

> Similarly, const_cast is error prone.

a member function would solve this.

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

Again, this won't work. Try it.

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

See above.

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

So just prohibit construction from a const object.

> > [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().

This is too trouplesome.

> Neither
> scoped_ptr nor scoped_array was designed to have container semantics.

yet they own the stored pointer.

br

Thorsten


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