[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: First Win32 Compile!



Bjarke Hammersholt Roune wrote:

>Wehee! PenguinPlay can now compile on a Win32 compiler!

Cool.

>I'm still getting one warning: "possible loss of data". This is because we
>are storing the time data in pak files in 64-bit fields, but we are only
>using a 32-bit memory structure to hold it (ppTimeT). I think this is a
>little counter-productive: we should either store time data in 32-bit fields
>in the pak files, or use a 64-bit memory structure to hold it.

Time values are stored in 64Bit in the Pak because that will be the
"normal" size for them in the near future (and AFAIK it already is on most
64Bit machines). When reading those I check whether the value read fits
into the local architecture's native time format, represented by ppTimeT.
If not, that means we cannot process this time data -> error. If yes, fine.

That is I do explicitly check for data loss.

It should be possible to do the check in a way that doesn't offend
compilers though.

BTW: the same situation exists for size and offset values. 

>Also, I've had to change the Name() method of a number of classes to get the
>const/unconst puzzle right. I have feeling that the Name() method really
>should be returning const char*'s rather than char*'s, and that it is the
>code that uses the return value as an unconst value that should be altered
>rather than the return type of Name().

I guess you're right.

>Btw, ever thougth about renaming accessor methods like Name() to GetName() ?

Yup. Later, when the updated coding standards are in place.


	Christian
--

Drive A: not responding...Formatting C: instead