469,909 Members | 1,985 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,909 developers. It's quick & easy.

Binary files

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

Thanks,
Alice walls

Nov 14 '05 #1
6 2050

"alice" <al***********@yahoo.com> a écrit dans le message de
news:11**********************@c13g2000cwb.googlegr oups.com...
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
Nov 14 '05 #2
alice wrote:
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
Nov 14 '05 #3
alice wrote:
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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Nov 14 '05 #4
"KiLVaiDeN" wrote...

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
Nov 14 '05 #5
KiLVaiDeN wrote:
"KiLVaiDeN" wrote...
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.


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.

--
Er*********@sun.com

Nov 14 '05 #6
> > 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.


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.
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.


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

Nov 14 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

27 posts views Thread by Eric | last post: by
9 posts views Thread by Ching-Lung | last post: by
8 posts views Thread by dagecko | last post: by
10 posts views Thread by joelagnel | last post: by
3 posts views Thread by nicolasg | last post: by
15 posts views Thread by JoeC | last post: by
3 posts views Thread by masood.iqbal | last post: by
9 posts views Thread by deepakvsoni | last post: by
reply views Thread by Salome Sato | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.