Mabden wrote:
"Denis Remezov" <fi***************@yahoo.removethis.ca> wrote in message
news:40***************@yahoo.removethis.ca... Rolf Magnus wrote:
Daniel wrote:
> Hi,
> What does the keyword const do for this function?
>
> virtual bool isUndoable() const { return true;}
It tells the compiler that the function does not modify the object it is
called for.
To elaborate a bit more for the OP:
It makes it possible to call this member function on a const object
or through a pointer or reference to a const object (the pointed to
object may or may not be const). That would not be allowed otherwise,
without a const qualifier.
It is possible, moral and typical for a const member function to
modify data members declared mutable.
Technically, it is possible for a const member function to directly
modify non-const non-mutable data members of a non-const object of
its class but only by casting away the constness (check out the thread
"const_cast, reinterpret_cast"). If the object itself or the data
member is const, this will cause undefined behaviour.
Wow! Uuuuhhh... can anyone translate Klingon to English; cos that was
Klingon to me!
Maybe a book written in english about C++ would not hurt.
The above is crystal clear :-)
OK. Simple.
Say you have a class (I leave out some details such as initialization
and just concentrate on the topic)
class Buffer
{
protected:
int Data;
int Time;
};
that has a member function:
class Buffer
{
public:
int foo() { return Data );
protected:
int Data;
int Time;
};
and now you use an instance of that class somwhere
int main()
{
const Buffer MyData;
cout << MyData.foo();
}
Then the compiler has a problem. In main you told the
compiler: MyData is constant. It will not change. But
in the next line you try to call a function foo on MyData.
Now how should the compiler know that foo() will not do
what the declaration promised: Don't change MyData. In
general it can't. Thecompiler might not see the implementation
of foo() at the point of call and thus cannot analyze if foo()
will not break the contract: MyData is constant and will not change.
The solution: Tell the compiler that foo() behaves and does not
change the object. That's what the const after the functions signature
is all about
:
class Buffer
{
public:
int foo() const { return Data );
protected:
int Data;
int Time;
};
When doing this, the compiler, when compiling foo, ensures that
none of the statements in foo() attempt to do a change in the
Buffer object.
class Buffer
{
public:
//
// the following is illegal.
// the function promises to not change the class intrnals
// but then tries to do so by assigning to Time
//
int foo() const { Time = 5; return Data );
protected:
int Data;
int Time;
};
But sometimes this is not the end of the story.
The point is: From the perspective of the user of an Buffer object,
the internals of that object are unimportant. It is the observable
behaviour that counts. That said: If foo() changes the Time variable
in MyData is completely unimportant, from the point of main() the MyData
object still hasn't changed, since there is no way to get at it.
A solution to this is to make Time a mutable member.
class Buffer
{
public:
int foo() const { return Data );
protected:
int Data;
mutable int Time;
};
This tells the compiler: Time may change, even for a constant object.
Thus:
class Buffer
{
public:
int foo() const { Time = 5; return Data );
protected:
int Data;
int Time;
};
becomes legal. It is as saying: foo() will not change the state
of the object, with the exception of Time. But since there is
no way for the user of this class to figure out that change,
it is ok.
--
Karl Heinz Buchegger
kb******@gascad.at 
