Re: portable issue of storing float point value in file
From: Almon B. Strowger (strowger_at_NOSPAM.kook.com)
Date: 05/13/04
- Next message: KS: "Scripting Engine for Pocket PC?"
- Previous message: Chris Tacke, eMVP: "Re: How to Change the Class id of an ActiveX control?"
- In reply to: Kenji Chan: "Re: portable issue of storing float point value in file"
- Next in thread: Kenji Chan: "Re: portable issue of storing float point value in file"
- Reply: Kenji Chan: "Re: portable issue of storing float point value in file"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 13 May 2004 11:58:43 -0700
Hi,
Why create a problem for yourself by doing a
memory dump?!
I have a feeling that you don't quite understand completely what
we've been telling you.
Here's what I understand you are doing at this point:
You now store Lat. & Long. in integer types and you need to
write them to a file that keeps data in a format that is consistent
from machine to machine and you are trying to write an application
that can be compiled to platforms of differing endianness without
any problems using the same data file for any machine.
So--Instead of steaming through memory and dumping an image
to the file (which would create the endianness problem.)
You do what I stated before--I will paste it in again:
DWORD fooData = 0xCAFEBABE;
BYTE a,b,c,d;
a = HIBYTE( HIWORD(fooData) );
b = LOBYTE( HIWORD(fooData) );
c = HIBYTE( LOWORD(fooData) );
d = LOBYTE( LOWORD(fooData) );
I'll try to explain it in more detail this time.
Imagine that fooData is one of your integers, say, a latitude.
What you do is break it up into bytes, and as per the
file format specification that you define, you write the bytes to
the file as bytes--not DWORDs. Maybe the HIBYTE and
LOBYTE macros confused you--They have NOTHING to
do with a higher or lower memory address--They have to do
with the higher or lower order bits of the represented integer.
Therefore, it doesn't matter how the integer is represented
in memory. So you take advantage of letting the compiler
deal with the endianness under the hood, so you don't have
to. And then, as andrew stated, when reading the data from
the file, you do it a byte at a time and reconstruct the integers
with something such as:
BYTE a, b, c, d;
// Read the bytes from the file here...
DWORD bazData = MAKELONG( MAKEWORD( d, c ),
MAKEWORD( b, a ) );
Hope this helps...
Almon B. Strowger
KOOK Pocket Software
"Kenji Chan" <no@no.com> wrote in message news:40a34641@dnews.tpgi.com.au...
> yes, it is a "memory dump" u can say
>
> > standard format, then the endianness issue has already been dealt with.
> > If this is a newly defined file format--Which it clearly seems to
> be--There
> > really is no issue here because unless a memory dump or a predefined
> > file or data transfer format is being used, the endianness problem need
> > not be a problem at all. No matter what the endianness of a machine
>
> no, e.g. a short like CD FF(hex) or 52735(dec)
> in one machine writes CD FF (big-endian)
> the other could write FF CD (little-endian) <-- most PCs
>
> > is, any machine can take a raw file and know the serial order of the
> > bytes that are read in. So just break the number into bytes and even
> > invent your own "endianness" for the file format if you want, eg.
>
>
- Next message: KS: "Scripting Engine for Pocket PC?"
- Previous message: Chris Tacke, eMVP: "Re: How to Change the Class id of an ActiveX control?"
- In reply to: Kenji Chan: "Re: portable issue of storing float point value in file"
- Next in thread: Kenji Chan: "Re: portable issue of storing float point value in file"
- Reply: Kenji Chan: "Re: portable issue of storing float point value in file"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|