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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-01-05 12:23:37

"David Abrahams" <dave_at_[hidden]> wrote in message
news:uptdytngi.fsf_at_boost-consulting.com...

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

Yeah, wrong word. proxy object should have smart prt

> > Otherwise a normal pointer would do.
>
> Really?  I (almost) never manage ownership of normal pointers.  That's
> what smart pointers are for.

see Above.

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

const member 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.

In some laguages it is just called a function; in others a query. The const
keyword
in C++ is the AFAICT the only way to support that in C++ with compiler
enforcement.

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

To have const in eg. the context of const member functions mean a "pure
function"
can never be in conflict with the language definition. The language enables
(but does not enforece) certain
idioms and const-correctness is one of them. The particular idiom of deep
const-correctness in const member-functions
is neither difficult to understand nor hard to justify. On the contrary,
it's hard to justify side-effects.

> You'll also have a hard
> time communicating with other programmers and will probably never get
> them to accept your definitions.

You're trying to make this into a pointless discussion about who's
definition is
better.

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

I guess so.

> > A function should preferable not have two puposes
>
> I don't see what that has to do with anything.

Well, a "pure function" computes something, nothing else. You wan't to make
 state changes of your program in a "pure function" which means that the
function must do
two things.

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

Not at all. You should listen better. I have argued many times why it
indeed a benefit for const member functions to propagate constness. To
recap:

* fewer or no sideeffects and better separation of concerns
* compile-time control over state-changes
* less surprising behavior

As our programs get bigger and bigger, these kinds of things start to
matter. That's
why it's even called a principle sometimes.Your best
counter answer has been that you don't agree; that's hardly an argument.
From
there I observed (no axioms here) that smart pointers don't support this
useful notion of const-correctness

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

I believe most of the cases have been a class that encompasses a
pointer and the pointee, at least that is where const member functions
come into the picture.

> Anyway, I think I'm done in this thread.  It's been fun,

indeed :-)

br

Thorsten