Skip to main content
gamedev.net
🔒 Locked

MSVC6 producing wrong code ?

Started by uNiQue0815 Dec 26, 2002 at 9:01 PM 6 replies 500+ views
Original Post
uNiQue0815
uNiQue0815
real big problem : i have a class which contains a public attribute (float). for testing purpose, i accessed it from within my main function : [my classes & code are much bigger... this is only for better understanding...] class myClass { public: virtual void accessattr(); float attribute; }; myClass *object = new myClass(); void myClass::accessattr() { attribute += 0.01f; printf ("%5.2f\n", attribute); } main() { object->attribute += 0.01f; printf ("%5.2f\n", object->attribute); object->accessattr(); } (that''s a VERY short verion of what i did... only the essentials for the bug...) setting the value of attribute in main(), i noticed that the value of attribute is not the same, as if i were accessing it from within a the member function. that''s weird, isn''t it ? then i tried the debugger and saw that the compiler produced the following for ''object->attribute+=0.01f'' within main() : mov ecx,dword ptr [object] fld dword ptr [ecx+40h] fadd dword ptr [] mov edx,dword ptr [object] fstp dword ptr [edx+40h] ...while it produced something like this for the access from within the member function : mov ecx,dword ptr [this] fld dword ptr [ecx+18h] fadd dword ptr [] mov edx,dword ptr [this] fstp dword ptr [edx+18h] when i deleted the line in main() and replaced it with the assembler-code & used 18h, instead of 40h, everything worked correctly... !? so what seems to be the problem ? think, this doesn''t happen in my example... only in bigger classes & projects. is the MSVC6 compiler buggy ? i''ve often had problems with MSVC-code (especially when compiling .dll files), while the same source compiled in linux/gcc (shared object) worked fine... i''ve just installed SP5... but that didn''t fix the problem...
Void
Void
It''s probably a case of uninitialized variables. Try explicitly initializing all your variables. Other compilers may by default initialize your variables.
aggregate
aggregate
Well, your code isn''t exactly well-formed to begin with.

Try this and repost results.

class myclass {
public:
virtual void accessattr() {
attr += 0.01f;
std:rintf("%5.2f\n", attr);
}
myclass(float attr_ = 0) : attr(attr_) { }
virtual ~myclass() { }
float attr;
};

int
main() {
myclass tmp;
tmp.attr += 0.01f;
std:rintf("%5.2f\n", tmp.attr);
tmp.accessattr();
return 0; // requires in MSVC6 or earlier
}

Sorry about the reformating, it''s too ingrained. Anyhow, that is easier to play with (and most importantly debug). Try that and see if nothing changes. I doubt most of that makes a difference, but I''m quite strict with C++ these days.

Well, I haven''t had a copy of VC++6 on my PCs, so I can''t test it out for ya. I''d recommend an upgrade to VS.NET, or better yet, wait for VS.NET 2003.
uNiQue0815
uNiQue0815
well, as a already said, this is not the code i''m having the problem with... it''s just a short version that describes what i''m doing, roughly...

the problem is not uninitialized variables (in fact i''m doing that, anyway). i also do have constructor & destructor (that''s where i init the variables).

i don''t talk about what value the variable has... it''s the fact, that the compiler produces code to access it at offset +40h and the right offset would be +18h ! (within member functions, the compiler inserts the right offset !... but not within the main() function)

i printed the address of the variable to screen (with &-operator) and compared with the object''s address... same thing...
the difference is 40h within main() and 18h within the member function... it''S not a runtime error... the offsets are set constantly in the compiled code. and these constants are just wrong !
antareus
antareus
Well as far as the offsets, remember that the virtual function table must be stored somewhere...
--God has paid us the intolerable compliment of loving us, in the deepest, most tragic, most inexorable sense.- C.S. Lewis
uNiQue0815
uNiQue0815
mmh.. maybe should have checked these answers sooner

i already found out about that ''two versions of the same header'' - problem. yes, that was it.

wow... that was a hard one... after hours of thinking & trying stuff, the idea that there could be two versions of the class came, while i was showering... good place to think, i guess


thx, anyway !

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.