Re: Telling an empty binary file from a "full" one
- From: Skarmander <invalid@xxxxxxxxxxxxxx>
- Date: Tue, 20 Sep 2005 00:45:48 +0200
Kenneth Brody wrote:
And by extension of that argument, "100% portable data" does not exist. There is only data that is read more and less easily by various languages on various platforms. But the intent is probably to literally convey the sense of effort one has to expend to hoist it from one end to another. ASCII-encoded integers are portable. Doubles encoded by someone's C implementation are too heavy.Christopher Benson-Manica wrote:
Michel Rouzic <Michel0528@xxxxxxxx> wrote:
That file is always 36 bytes big (it contains 4 double-precision floats and one integer) and i'd like to be able to test whether it is 36 bytes long or not, but it seems like quite a big problem to get to do it in a portable way.
If you're assuming it will always be 36 bytes in size, you've already left the realms of strict portability. Is there any particular reason you're unable to simply store what sounds like a small amount of data as text? It would make many things easier, in any case.
s/36 bytes/4*sizeof(double)/
In my mind, there's a world of difference between "portable code" and "code that generates portable data files". (One could also argue that writing the file as text isn't 100% portable, as ASCII files won't read correctly on an EBCDIC system.)
If your program is writing files, it's doing so because it needs to communicate something across process boundaries. By some Rule or Law someone no doubt coined, the mere potential to do things inspires the desire to have them done. Therefore, it's wise to accommodate as broad a range of processes as you can afford.
Writing binary data in the native format of your C implementation is probably the narrowest range possible, and only justifiable by laziness. It may be justifiable laziness, of course, but it's still laziness. Know that it only works if the process on the other side of the boundary is a program compiled by the exact same C implementation, running on the exact same platform. Even upgrading your C library is taking chances -- very mild ones, but you should nevertheless be aware of them.
What am I saying? Oh yes, right. What the other posters said. Use a text file. It's really not much more involved and saves you ever so much potential grief.
S. .
- Follow-Ups:
- Re: Telling an empty binary file from a "full" one
- From: Michel Rouzic
- Re: Telling an empty binary file from a "full" one
- References:
- Telling an empty binary file from a "full" one
- From: Michel Rouzic
- Re: Telling an empty binary file from a "full" one
- From: Christopher Benson-Manica
- Re: Telling an empty binary file from a "full" one
- From: Kenneth Brody
- Telling an empty binary file from a "full" one
- Prev by Date: Re: Questions about pointers to objects and pointers to functions
- Next by Date: Re: Telling an empty binary file from a "full" one
- Previous by thread: Re: Telling an empty binary file from a "full" one
- Next by thread: Re: Telling an empty binary file from a "full" one
- Index(es):
Relevant Pages
|
