Subject: Re: Compiler strictness
From: Mike Nordell (tamlin@algonet.se)
Date: Sat Feb 03 2001 - 10:37:34 CST
Charles Lechasseur wrote:
> actually, i think using const for a member function is not exactly like a
> const variable.
Agreed. I'ts quite different.
> if you had a const EV_Menu_Label** mArray, then yes, you
> could probably get away with what you mention above.
But, that's what we have. We have a member
EV_Menu_Label**
and within a const member function, where the implicit this is "const" the
type _is_
const EV_Menu_Label**
> but in a const method you're not supposed to modify the
> object *at all*, which is definitely not
> what you are doing above.
Either I have to say "correct" or "wrong" depending on how I take your
comment.
In C++ "const" is not "deep". In this case you _are not_ modifying the class
itself or _any_ of its data members. You're modifying a non-const object
pointed at by a const pointer. This _is_ the correct behaviour.
> even if the compiler does not enforce it, it's probably better not to flag
> a method as "const" if it can actually modify the object.
Agreed. But in this case we're not modifying the object, we're modifying
something a pointer in a pointer in the object points to. This has been a
source of several threads of discussion in at least comp.lang.c++.moderated
(search deja) why it's would just be reiterating the arguments to hold this
discussion here.
If that object (x) was really to be const inside that class (y), that object
(x) was designed in the wrong way. If you'd like to enforce constness of
even the pointed at elements you should _tell so_ in the class.
It is an error in the Apple compiler, and the one using it should report
that error.
/Mike
This archive was generated by hypermail 2b25 : Sat Feb 03 2001 - 10:35:57 CST