Subject: Re: Compiler strictness
From: Charles Lechasseur (danov@sympatico.ca)
Date: Sat Feb 03 2001 - 16:00:24 CST
>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.
i checked with Metrowerks CodeWarrior on the mac. CW handles it correctly
(i.e., the way gcc handles it, it doesn't complain). i also understand the
*technical* reasons why this is so, and i was mistaken in the first place.
sorry about that.
however, i still think that listing this method as const is a bit of a
misnomer. if i am correct, the EV_Menu_LabelSet assumes ownership of the
EV_Menu_Label* you store in m_labelTable. if this is the case, then calling
getLabel is somewhat confusing.
if i was looking at the class declaration, from looking at getLabel, i
would assume, since it is const, that it would either return the label that
corresponds to the id i pass in or, if no label has that id, it would
return NULL. but here if the id is not yet defined, it actually *creates* a
menu label, stores it in the labelTable and returns it. this is a strange
side-effect of the method, i think. of course it is surely the intended
behavior; i'm just saying it would probably be less confusing to remove the
const keyword from that method.
after all, if m_labelTable was declared as
EV_Menu_Label* m_labelTable[SOME_FIXED_SIZE];
then the code would give an error, even though what i did here is just set
a predefined size for the array. i understand that from a technical point
of view a static definition like this is very different from a dynamic
allocation like the class currently uses; all i'm saying is that either
arrays would actually be used the same way for the same purpose.
my 2¢ of course.
--charles lechasseur - danov@sympatico.ca http://www3.sympatico.ca/danov/marathon/
"The butts of evil are awaiting my bootprints!" - Minsc
This archive was generated by hypermail 2b25 : Sat Feb 03 2001 - 16:01:28 CST