[boost] Re: Interest in smart pointer with value semantics?

From: David B. Held (dheld_at_[hidden])
Date: 2004-01-04 00:53:37

"Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
news:bt8513$l3a$1_at_sea.gmane.org...
> "David B. Held" <dheld_at_[hidden]> wrote in message
> news:bt827b$hvp$1_at_sea.gmane.org...
> > [...]
> > 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
correct?

> 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)
{
    p->nonConst();
}

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

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

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

Dave

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