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

From: David Abrahams (dave_at_[hidden])
Date: 2004-01-05 10:38:37

Thorsten, something about the way you're posting results in mangled
quotes.  I think it has to do with starting your own, new lines with
">"

"Thorsten Ottosen" <nesotto_at_[hidden]> writes:

>>Q41: What is `const correctness'?
>>A: A program is `const correct' if it never mutates a constant object.
>
> You OTOH seem to think this is ok. I guess it ultimately depends on
> what actually constitutes the object.

Yes!

> Since our views differ here, so will our definition of const
>conrrectness.  From a smart pointer that takes ownership, I have
>stated that I think of it as if the proxy-object owns the stored
>object, not just the pointer.

Ah, but a proxy-object and a pointer are different idioms.

> Otherwise a normal pointer would do.

Really?  I (almost) never manage ownership of normal pointers.  That's
what smart pointers are for.

>>Q45: What is a `const member function'?
>>
>>A: A const member function is a promise to the caller not to change
>>the object.  [...]  Some programmers feel this should be a signal to
>>the compiler that the raw bits of the object's `struct' aren't going
>>to change, others feel it means the *abstract* (client-visible)
>>state of the object isn't going to change.
>
> So this definition is sufficiently vague to include both our
> views. As you properly know by now, I'm in favor of calling
> functions without program-wide side-effect for const-correct. 

Oh, a function that has side-effects is not const-correct?  I suspect
that no other programmer on the planet shares that definition of
"const-correct."

> If you call a const function

What's a const function?

> on an object and it changes the state of the program st. other
> functions might behave differently, it is fraud. 

OK, but I never call anything a "const" function.  I would call that a
"pure" function, per Andrei and Dave H's recent CUJ article.

> You say to your client that you're not going to change the state of
> the system, but you do it anyway.  

That's not what `const' says.  There's a reason that const applies to
specific objects and types:

  void f(
       const int& x  // can't mutate through x
     , int& y        // can mutate through y
  );

Hint: you can make up your own meanings, which don't agree with the
language definition, for terms such as `const', but it'll be a
struggle for you because they'll behave according to the language and
not according to what you want them to do.  You'll also have a hard
time communicating with other programmers and will probably never get
them to accept your definitions.

> Of course you could document it, but it would be much better and
> clearer to simply make another function that is not const. From your
> Zen of Python: Explicit is better than implicit.  

Absolutely.  I can be as explicit as you want about `const', but if we
can't agree on a meaning for the term you're always going to feel I'm
violating the contract.

> A function should preferable not have two puposes

I don't see what that has to do with anything.

>, comp. Herb Sutter's books.

>>From Eiffel I remember the Query-Command separation principle. From pascal
> it was called function and procedure. Good stuff.
>
>> >> For someone to claim that, she'd have to prove that there
>> >> is some self-contradiction in it, which I don't think is the case.
>> >
>> > The contradiction lies in those who argue const-correctness is good,
>> > yet don't want it in one of the most important places.
>>
>> Your argument starts, again, from the position that the status quo for
>> smart pointers lacks const-correctness.  It further presumes an agreement
>> on what the "important places" for const-correctness are.
>>
>> > That's inconsistency.
>>
>> No, that's circularity.
>
> Not understood.

Your argument relies on the fundamental issues in question as
premises.  You take as an axiom that smart pointers lack
const-correctness and that it's well-understood what the "important
places" for const-correctness are.

> Anyway, from this definition
>
>>Q41: What is `const correctness'?
>>A: A program is `const correct' if it never mutates a constant object.
>
> we cannot infer anything, because we don't know what an object
> is. The fact that you don't think of the object in a deep sense is
> an open door for bugs and surprising behavior.

One could say the same about the fact that you think of something
called a "pointer" as encompassing its pointee.

Anyway, I think I'm done in this thread.  It's been fun, but I don't
have any further points to make. So take them or leave them, I guess.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com