Binary files

[alice]

hi all,
Can anybody please tell the advantages which the binary files offers
over the character files.

Thanks,
Alice walls

 

[KiLVaiDeN]

hi all,
Can anybody please tell the advantages which the binary files offers
over the character files.

Thanks,
Alice walls

Direct data access I think mainly.

K

 

[Default User]

hi all,
Can anybody please tell the advantages which the binary files offers
over the character files.

What do you think? Do you know what the differences are? Why do you
want to know? What problem are you trying to solve.

Various file types are correct for various problem sets. There is no
blanket answer.




Brian

 

[Michael Mair]

hi all,
Can anybody please tell the advantages which the binary files offers
over the character files.

Sounds a little bit like a homework assignment.

I'll take the risk:
Let us assume we have a platform/implementation with bytes of
8 bits and 32 bit ints and 64 bit doubles which can be considered
IEEE doubles.
Now, if you store a very small negative integer number, say
-1000000000, you need (up to) 11 bytes whereas storing it in
binary takes only 32/8=4 bytes; similarly for doubles:
Storing a number as text (decimal fraction) takes up to 23
bytes whereas the binary takes only 8 bytes.
So, you save some (disk) space.

On the other hand, the binary representation on another
platform may be different which means that you can no longer
use the old files. Storing everything as text means that
you only have to use a standard tool for text file conversion
and can further use your old data files.
Another point: If everything is written out as text, you are
able to manually tweak the data if needed, only using a simple
text editor. Tweaking binary files usually is not much fun...

Have also a look at the comp.lang.c FAQ. It is probably best
if you download the text version and just search for "binary":
ftp://ftp.eskimo.com/u/s/scs/C-faq/faq.gz
For the HTML version start from here:
http://www.eskimo.com/~scs/C-faq/top.html


Note that this answer is not "complete"; there are of course
platform-independent "binary" files but there you do not store
objects from the memory directly to the file but convert them
to a certain format beforehand.


Cheers
Michael

 

[KiLVaiDeN]

Direct data access I think mainly.

K

By that I mean that with binary files, you can do some "structures" like
chained list or b-trees quite easily, while with character files it's pretty
hard.
Binary files are much more flexible, and since each "row of data" is
supposed to have the same size, you can access very fast to any data in the
file by moving from the "date size" in bytes, which is impossible in
character files.
Also as it was alrdy said, in binary files you can store real
representations of datas like ints, doubles, or any other data ( it's called
"serializing data" by the way ) which is once again impossible to do in a
character file, which is only a "string" representation of data.

K

 

[Eric Sosman]

...



By that I mean that with binary files, you can do some "structures" like
chained list or b-trees quite easily, while with character files it's pretty
hard.

Agreed, as a generality.

Binary files are much more flexible, and since each "row of data" is
supposed to have the same size, you can access very fast to any data in the
file by moving from the "date size" in bytes, which is impossible in
character files.

You lost me there: binary files are more flexible because
they're more rigid? You're confusing the unrelated concepts
of structure and encoding.

Also as it was alrdy said, in binary files you can store real
representations of datas like ints, doubles, or any other data ( it's called
"serializing data" by the way ) which is once again impossible to do in a
character file, which is only a "string" representation of data.

Nonsense. As a trivial counter-example, consider UUencoded
data streams: entirely textual (and from a limited character
set at that), yet capable of representing any arbitrary bit
pattern.

 

[thesagerat]

Binary files are much more flexible, and since each "row of data"
is

You lost me there: binary files are more flexible because
they're more rigid? You're confusing the unrelated concepts
of structure and encoding.

Easier to parse. If you have a bitmap where each row of pixels will
take up 256 bytes, you just have to add 256 to your current position to
move down a pixel. If we tried writing a bmp as a text file like below
(and I mean saved as ascii):

0 0 0 0 0 0 0 0 0 0
256 256 256 256 256 256 256 256 256 256
0 0 0 0 0 0 0 0 0 0
256 256 256 256 256 256 256 256 256 256

Then you're going to have to count the number of space ' ' characters
and end of line characters '\n' (maybe "\r\n") to find the next pixel
row and desired pixel. Then you will need to convert the ascii
characters '0' or '2''5''6' into a binary representation that your
computer understands. It will be a little bit easier if you save your
text file as:

000 000 000 000 000 000 000 000 000 000
256 256 256 256 256 256 256 256 256 256
000 000 000 000 000 000 000 000 000 000
256 256 256 256 256 256 256 256 256 256

as at least then you can use simple math to calculate the position of
the start of each ascii representation of the values.

Nonsense. As a trivial counter-example, consider UUencoded
data streams: entirely textual (and from a limited character
set at that), yet capable of representing any arbitrary bit
pattern.

You can represent any pattern using only hieroglyphs, that doesn't mean
that your program can just suck it in and go without extraneous
overhead.

For instance, one can do things like:

struct pixelData {
unsigned char r;
unsigned char g;
unsigned char b;
} myData[10][4];

read(fhandle, (char*)myData, sizeof(myData));

And have all of your data filled into your multidimensional array and
ready without a single ounce of conversion.
(Note that this may not be safe dependent on the source and kind of
data.)
UUEncode will first require that the text data is unencoded.

-Chris