stbenge wrote:
> as you suggested. I found out that by not explicitly assigning "val" (or 
> tempFx, tempFy) an initial value, it was picking up nonsense and 
> carrying it through as it read through the stream.

That doesn't make a whole lot of sense. fread() should be overwriting the 
value. You might want to check the return value from fread to make sure 
you're getting what you think you're getting. Plus, using sizeof(int) is 
probably a better idea than "2".  If it's really 2 and not sizeof(int) in 
your data file, then you ought to be reading 2 unsigned chars and doing the 
math to turn them into an integer lest you get endian problems. Remember 
that &xyz doesn't necessarily point to the low byte of the integer.

I.e., it would be better to do something like
   unsigned char buf[2];
   if (2 != fread(buf, 2, 1, fieldFile)) {
     printf("Whoops!");
     exit(1);
   }
   val = buf[0] + 256 * buf[1];
   /* That only works for unsigned integers, btw */

If you have four-byte integers, I wouldn't bet the way you've written it 
works correctly. Especially not for signed values.

> I do not know why it 
> would act this way inside a class member but not in other scenarios, but 
> I suspect it has to do with how C++ allocates memory.

Well, data of global lifetime is specified as being initialized to 0 unless 
otherwise initialized. It could just be whatever random crap was in your 
RAM, if both classes and variables were stack allocated.

> I may need to use these values another time, so I left 
> that functionality in the binary format.

Ok. The better thing to do here would be to check that tempFx and tempFy 
match fieldWidth and fieldHeight, if it's your intention that they always 
match. Then the reader knows what you're talking about, plus you get a 
chance to blow up if you later feed it the wrong data file.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message