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...

It''s probably a case of uninitialized variables. Try explicitly initializing all your variables. Other compilers may by default initialize your variables.

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.

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 !

In order to show a bug in the compiler, you need to give a reproducable example (that happens with latest service pack applied). Also include a command line how you compile and link. It''s really hard to guess when the bug shows otherwise. There have been bugs in msvc compiler, but with latest service packs applied, it''s unlikely that your problem depends on the compiler - or at least you have to prove it.


> especially when compiling .dll files

It''s unlikely that the compiler generated result would differ depending on how you link.

IF YOU INITIALIZE YOUR VARIABLES PROPERLY, read next

We had this once because we had two versions of the same header at different places and there were different definitions of the classes.
Check this

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 !