Boost logo

Boost :

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
> news:bt827b$hvp$
> > [...]
> > 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 (
Version: 6.0.556 / Virus Database: 348 - Release Date: 12/26/2003

Boost list run by bdawes at, gregod at, cpdaniel at, john at