difference between binary and "regular" file output?
Author
high,
im wondering, what is the difference between writing to a file in binary mode, and writing to the file in "regular" mode. i really have no clue what is meant by "binary" mode. also, what are the advantages/disadvantages of either one? which would be more suitable for an error/success logging system? thanks for any help!
Donkey Punch Productions.net
"Regular" file output is typically formatted text: text strings, numbers represented in text format as strings of ASCII symbols or characters, etc... with end-of-line characters to mark the ends of lines, and whitespace to delineate strings. Binary is not. Binary data can not be assumed to be character string data; it frequently contains embedded zeroes, and does not interpret end-of-line characters as end of lines. There are no "lines" as such; it is just a block of bytes. Integers, floats, doubles and such are not converted to character strings, but are written as-is, as raw binary data.
Consider an integer, i=143592. When writing to a text file, you can write it using the C++ << stream operator, as so:
File << i;
If File is opened in text mode, this writes the human-readable character string "143592" to the file. This string can later be read back into i:
File >> i;
This reads in a string of bytes, eliminating pending whitespace and stopping again when whitespace or EOL is encountered, then converting the text string into an integer. The storage space used by the integer is 6 bytes, not counting whitespace or end-of-line separators.
Binary file output in C++ is accomplished using the write() function, which takes a pointer to a block of bytes, and writes those bytes as raw data to the file. So the line:
File.write((char *)&i, sizeof(int));
will write 4 bytes (or however many bytes an int occupies on your platform) to the file, and those bytes will be the actual in-memory byte values representing the integer. The integer is not converted to a character string first, so it can not be read back as a character string using >> and is not human-readable. Instead, it must be read back using the read() function:
File.read((char *)&i, sizeof(int));
This function will read exactly 4 bytes (or, again, the size of an int on your platform) into i. File >> i on a binary file is likely to give you gibberish, reading arbitrary bytes and un-printable characters until the next whitespace or EOL is encountered.
The difference can be very significant. No matter what value an int holds, for instance, it will always take up exactly sizeof(int) (4, for 32-bit ints) bytes in a binary file. Whereas with a text file, it takes up 1 byte for each digit in the value. For 32-bit integers, you can burn 10 or 11 bytes holding the character string ("2147483647" or "-2147483648"). For large sets of data, this can quickly balloon.
Similarly with floats and doubles and all the other types.
For logging, you will want to go with text-mode files, as they can be opened in a text editor for reading. Binary files would open as unintelligible gibberish, similar to what you would get if you opened an executable file in Notepad, for instance. Binary files are best for large chunks of data that do not need to be human-readable, such as bitmaps, mapfiles, model-data, etc...
Golem
Blender--The Gimp--Python--Lua--SDL
Nethack--Crawl--ADOM--Angband--Dungeondweller
Consider an integer, i=143592. When writing to a text file, you can write it using the C++ << stream operator, as so:
File << i;
If File is opened in text mode, this writes the human-readable character string "143592" to the file. This string can later be read back into i:
File >> i;
This reads in a string of bytes, eliminating pending whitespace and stopping again when whitespace or EOL is encountered, then converting the text string into an integer. The storage space used by the integer is 6 bytes, not counting whitespace or end-of-line separators.
Binary file output in C++ is accomplished using the write() function, which takes a pointer to a block of bytes, and writes those bytes as raw data to the file. So the line:
File.write((char *)&i, sizeof(int));
will write 4 bytes (or however many bytes an int occupies on your platform) to the file, and those bytes will be the actual in-memory byte values representing the integer. The integer is not converted to a character string first, so it can not be read back as a character string using >> and is not human-readable. Instead, it must be read back using the read() function:
File.read((char *)&i, sizeof(int));
This function will read exactly 4 bytes (or, again, the size of an int on your platform) into i. File >> i on a binary file is likely to give you gibberish, reading arbitrary bytes and un-printable characters until the next whitespace or EOL is encountered.
The difference can be very significant. No matter what value an int holds, for instance, it will always take up exactly sizeof(int) (4, for 32-bit ints) bytes in a binary file. Whereas with a text file, it takes up 1 byte for each digit in the value. For 32-bit integers, you can burn 10 or 11 bytes holding the character string ("2147483647" or "-2147483648"). For large sets of data, this can quickly balloon.
Similarly with floats and doubles and all the other types.
For logging, you will want to go with text-mode files, as they can be opened in a text editor for reading. Binary files would open as unintelligible gibberish, similar to what you would get if you opened an executable file in Notepad, for instance. Binary files are best for large chunks of data that do not need to be human-readable, such as bitmaps, mapfiles, model-data, etc...
Golem
Blender--The Gimp--Python--Lua--SDL
Nethack--Crawl--ADOM--Angband--Dungeondweller
Absolutely (almost) no difference. The only reason why its important on Windows is that when you write to a file in text mode, each newline you write is written as a combination of two characters: newline and carriage return. When reading a file in text mode, the reverse happens: newline and carriage return as converted to just a newline. So go ahead and write a struct to a file in text mode and read it back. It breaks apart when you try to seek in a file because that extra carriage return will make your calculations off by one, that''s where binary mode comes into play: it doesn''t use the carriage return and your off by one error disappears. Other than that, binary and text modes are equivalent and if you''re clever, you can use either one for anything.
Yep - using non-binary files for writing out binary data is asking for trouble (on DOS/Windows platform anyway). It converts any newline to CR,LF even inside a binary data structure.
This is as far as I can tell, basically a hack to get Unix C programs to work on DOS / Windows (i.e. they don''t see the CR when reading, and write an extra one when writing). But it stuck.
Mark
This is as far as I can tell, basically a hack to get Unix C programs to work on DOS / Windows (i.e. they don''t see the CR when reading, and write an extra one when writing). But it stuck.
Mark
I never use regular file access even when writing regular data. I always use binary files and write EOLs manually. I never experienced any problem using this approach. In fact, I think there''s no need to have these two modes and I don''t understand why they do exist. I think that there is no problem to have only one mode (binary of course) and use fprintf to write regular data to it (and vice versa fscanf) among with fread and fwrite.
If you had to write floats in a binary file, how would you read them back? The reason I wanted to use binary is so you wouldn't get the problem of converting back from char to float. One of the replys said binary is used for large amounts of data, but what if you only had to get a couple of floats. Would this work,- Write 2 floats, then read back with
File.read((char *)&i, 2*sizeof(float));//(modified from post above).
But then how would you actually allocate your 2 floats (or what ever in your program), to the two floats just read out of the file?
Thanks
[edited by - Stevieboy on April 16, 2004 6:03:06 PM]
File.read((char *)&i, 2*sizeof(float));//(modified from post above).
But then how would you actually allocate your 2 floats (or what ever in your program), to the two floats just read out of the file?
Thanks
[edited by - Stevieboy on April 16, 2004 6:03:06 PM]
Author
ok, so im confused now. is binary file output human readable? if i write in binary, and open the text file, can i read it?
quote:Original post by graveyard filla
ok, so im confused now. is binary file output human readable? if i write in binary, and open the text file, can i read it?
text format is readable
binary format is unreadable
in short, the answer to your question is no.
quote:
text format is readable
binary format is unreadable
in short, the answer to your question is no.
now i''m going to mess things up a little more
. the above statement is not correct as-is.binary format actually CAN be readable. you can write strings in a binary file and you WILL be able to read them if you open the file in a text editor.
as mentioned above, a simple sample pointing out the difference between text and binary mode is when it comes to write numbers into the file.
just think of a text file like a binary file holding only values within humanreadable range. (that means, numbers, abcdefghijklmnopqrstuvwxyz and so on)
Indeterminatus
--si tacuisses, philosophus mansisses--
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
