[...]
What is the state of an object?
That is, of course, the crux of the problem. As far as the
compiler is concerned, it is the bits that make up the object
itself, i.e. that are counted in sizeof. Most programmers
expect more, however; in the end, the state of an object is what
the author of the class documents as its state.
A state of an object is supposed to be a set of data that
determines the behavior of an object.
Not quite. Would you consider the machine connected at the
other end as part of the state of a Connection object? It's not
even part of the program.
In another word, knowing the state of an object would dictate
what its functions do given some inputs.
They do, within defined (and in well written code, documented)
limits. A print function, in an object, might output a time
stamp (which will vary each time it is called, and is
independant of the state of the object), if that's what it is
documented to do. For that matter, an object could be defined
to do one thing if the number of seconds since the epoch is odd,
and another if it is even. (Whether such an object has any
practical use is another question, of course.)
Otherwise, what is the point of knowing an object's state?
It constraints the behavior.
So, if you say that declaring an object 'const' should keep
its state constant, then its member functions should yield the
same output for the same input since the object remains in the
same state!
That's an enormous leap, and I don't know where you get that
idea from.
However, this is not the case as shown in the example.
Rigorously, all 'const' really does is that it is a switch to disable
the invocation of certain member functions --- those that are not
declared 'const'.
Const means whatever the programmer wants it to mean. Yes.
In the end, classes are really about contracts. The author of
the class defines its contract. If he's a good programmer, it
will be a reasonable and useful contract, and const will have
some sort of relatively reasonable and intuitive meaning. It
won't mean (necessarily) that every invocation of a const
function will return the same value.
And of course, a bad programmer could abuse const (and mutable)
so that only the const functions modified the state, and the
non-const ones didn't. The language allows it, but such a
programmer won't last long in any place I've worked. The
language doesn't impose good design; I don't think a language
can, since it works at a much lower level. (The lack of any
errors in your English doesn't mean that you write at the same
level as Shakespeare does, either.)