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

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-01-05 07:25:24

"David Abrahams" <dave_at_[hidden]> wrote in message
news:uekuebrx1.fsf_at_boost-consulting.com...
> "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
[snip]
> > AFAIK the language does not on its own have a definition of
> > const-cerrectness.  I've never seen it mentioned in the
> > standard. What is good is that the language allows us to pursue
> > const-correctness *if* we want to.
>
> And, define it!  I like the definition here:
>
>    http://docs.xbe.ch/arch/dev/cplusplus/part10.html
>
> or here, this one's a bit loose, but it is similar:
>
>    http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.1
>
> I suspect the first one matches most other peoples' definition.

A haven't seen the first earlier, but I like it.

> What's your definition?

I don't see anything in the first that contradicst my view. Eg,

>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. 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. Otherwise a normal pointer
would do.

>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. If you call a const function on an object and it changes
the state
of the program st. other functions might behave differently, it is fraud. Yo
u say to your
client that you're not going to change the state of the system, but you do
it anyway.
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.
 A function should preferable not have two puposes, comp. Herb Sutter's
books.

>Q46: What is an `inspector'?  What is a `mutator'?
>A: An inspector inspects and a mutator mutates.  These different categories
of
>member fns are distinguished by whether the member fn is `const' or not.

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

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.

br

Thorsten