From: David B. Held (dheld_at_[hidden])
Date: 2004-01-04 00:53:37
"Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
> "David B. Held" <dheld_at_[hidden]> wrote in message
> > [...]
> > Is this code not const-correct?
> I don't see your point, but yes.
I don't understand your answer. Yes it is correct, or yes it isn't
> If we have a const member functions I want (and many others)
> constness to propagate to members pointers or not. If an
> argument is const, I don't wan't to change the argument <g>.
All I was saying is that a const member function can call functions
that are non-const and still be const-correct. I really don't know
what you are saying.
> > It looks like you are missing the fact that const smart_ptr<T> is
> > really analogous to T* const. Now, if you are arguing that T* const
> > should be the same as T const*, that's an entirely different ball of
> > wax.
> I'm certainly not trying to do that.
But you're saying there's no reason for us to even have
smart_ptr<T const> be different from smart_ptr<T> const. So to me,
you are arguing that T const* should be the same as T* const, because
that is what is "most useful to real users".
> Instead of thinking about syntax, think about usefulness. I have
> repeatedly asked for real examples where the current behavior
> is really needed and none has come up with them.
What about Peter Dimov's example? All you said was: "I would do
it differently." Well, you can do just about anything differently in C++,
so why should we come up with any examples? The fact is, this is
an extremely common idiom:
void foo(shared_ptr<X> const& p)
I know, because I've done it hundreds of times. And yes, I do want
the & to be const, because I don't want to accidentally reset() the
pointer in the function. *That's* const-correctness.
> 1) Many people don't like that behavior
So far, you're the only one here who's said so. If there's so many
other people who don't like that behavior, I wonder where they are?
Mr. Wallin argues for deep const for deep copy, but I don't see him
saying anything about shallow copy pointers.
> 2) Those people can't get what they want easily
Sure they can't. You still haven't shown how smart_ptr<T const>
does *not* give you what you want. You said something about
"unconditional const", but that didn't parse at all. Tell me exactly
which parts of the smart_ptr<> (or shared_ptr<>, since it relies
on the same syntax) interface are unsatisfactory under these
> 3) If the design is changed, those who favor the current design
> can get what they want easily
No they can't. They have to use const_cast<> and/or mutable to
get what they want. On the other hand, using the current design,
users only need to use smart_ptr<T const>, which requires no
ugly and potentially dangerous casts or other code changes.
> 4) The property that const smart_ptr<T> must absolutely be equal
> to T* const has not been justified
A) When writing a drop-in replacement for an existing facility, it is
best to emulate that facility as much as is reasonable. B) It allows
for proper const-correctness without ugly hacks. What has not been
explained is how const_cast<> is *not* a hack, but
smart_ptr<T const> *is*. That's exactly backwards in my world.
> in any way; It seems that the use for it is seriousely limited
If you consider passing a pointer by const& a "seriously limited"
> If you add to this that smart pointers is going to be used in almost
> any future C++ program, it should be serving most people needs.
Considering how long shared_ptr<> has been around, the number
of programs it's been used in, and that fact that the only real gripe
with the constness of shared_ptr is in the copy cost for shared_ptr<T>
to shared_ptr<T const>, I'd say that it is serving most people's needs
quite well. In fact, you have not demonstrated the contrary.
> I have no intension to prohibit those who wan't to bypass the type
> system, but I would appreciate that I can use it if I wan't.
Umm...*you* are the one suggesting that people use const_cast<>
so that deep-const semantics can be the default! How on earth can
you pretend that you are using the type system and everyone else
is "bypassing" it?? This is sheer madness!
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk