|
Boost : |
From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-01-03 10:55:51
"David Abrahams" <dave_at_[hidden]> wrote in message
news:u3caxnln7.fsf_at_boost-consulting.com...
> "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
>
> > "David B. Held" <dheld_at_[hidden]> wrote in message
> > news:bt5trp$s2m$1_at_sea.gmane.org...
> >> "Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
> >> news:bt5ip0$ge1$1_at_sea.gmane.org...
> >> > [...]
> >> > Having propagation of constness makes a lot of sense and
> >> > would certainly make the smart pointers a lot smarter.
[snip]
> >
> > Why? Can't you cast the constness away?
>
> A const_cast is an open door to undefined behavior.
Please show me an example of how you get this. There's no reason that it
should be
a const_cast, it could be smart_ptr_cast or smart_ptr.get_naked_ptr().
> The language is
> designed to make most casts unneccessary by providing a type system
> which separates the constness of an object from the constness of
> objects *reachable* from that object. That's why char const* and
> char*const are different types.
What has this got to do with our discussion? AFAIK, most of the pointer
semantics
are inherited from K&R C which has no notion of const, let alone const
member functions.
> > I really don't understand why correctness should not be the default
> > and then let those who want it do the hacks?
>
> It's the system which requires const_cast that is the hack. The
> language is correct and consistent as it stands.
So don't use the hack, but make the smart pointer a little bit more usable
by providing overloads.
The smart ptrs does not seem to be consistent with good design principles.
One thing is the language,
another thing is its use and its idioms.
> It would only make sense in C++ to make a pointee's mutability depend
> on the mutability of the pointer if we were going to think of the
> pointee as being part of the pointer.
which is the case of any smart pointer that takes ownership of the pointer.
Not even scoped_ptr
does this.
I recall an old dicussion found here:
Most people seems to favor propagation of constness.
I'm just trying to see a glimse of all those useful examples that justify
this giant loophole
in the const-correctness of our programs.
br
Thorsten
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk