Skip to main content
GameDev.net gamedev.net
🔒 Locked

Moving a variable declaration affects unit test...

Started by King of Men Apr 18, 2015 at 8:34 PM 4 replies 2.3k views
Original Post
King of Men
King of Men

So if I declare my class this way:


private:
  vector<ContractInfo*> obligations;
  map<EconActor*, double> borrowers;
  double discountRate;

then my unit tests fail. But if I do it this way:


private:
  double discountRate;
  vector<ContractInfo*> obligations;
  map<EconActor*, double> borrowers;

they pass. My heart fills with unbounded joy at the thought of tracking this one down...

I suspect I have a destructor somewhere that I ought to have declared virtual, but didn't. Any better guesses?

To win one hundred victories in one hundred battles is not the acme of skill. To subdue the enemy without fighting is the acme of skill.
wintertime
wintertime

Maybe you use one member in the constructor for initializing the other and as the construction order depends on their declaration order it may change the outcome.

King of Men
King of Men

Nope, the members are all independent. Good one, though - I'll keep it in mind for the future.

To win one hundred victories in one hundred battles is not the acme of skill. To subdue the enemy without fighting is the acme of skill.
King of Men
King of Men

Turns out I was looking up an un-initialised variable, interpreting it as double, and consistently getting NaN in one case and some small but numerical value in the other. Not sure why the variable location should so consistently flip me between NaN and number, though. Unless perhaps it is the struct layout that does it; the value in question comes from dereferencing the end of that map.

To win one hundred victories in one hundred battles is not the acme of skill. To subdue the enemy without fighting is the acme of skill.
jpetrie
jpetrie

You may have changed the size of the class due to additional (or few) pad bytes inserted by the compiler to correctly align the members. Check sizeof(the type) before and after, or use /d1reportSingleClass layout in VS.

alh420
alh420

Turns out I was looking up an un-initialised variable, interpreting it as double, and consistently getting NaN in one case and some small but numerical value in the other. Not sure why the variable location should so consistently flip me between NaN and number, though

Probably just coincidence...

Even though the value in this case is "undefined", in practice, it can be deterministic.

It probably was initialized as part of another object, that then went out of scope, and the memory then reused for this object.

Topic Locked

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

Sign in to reply to this topic.