I will definitely aim to have future numeric values in my files written in binary for the sake of an making the file easier for the program to read. |
Using binary mode won't necessarily make a file easier to read. In fact, IMO, binary mode makes things more difficult because it is harder to tell what the file contains. Also binary mode is not portable so if you write the files on one system there is no guarantee that you can easily transfer the contents to another system.
As for the \0, I guess that's similar to the binary issue where I would want to have an editor program to attach that to all strings when it is written to the file. |
If you write a string to a file you should write the end of string character to the file, that end of string character is what makes a string a string and not just an array of char.
As you mentioned in your last part, I'll probably stick with text mode for this current project I'm working on, mainly because I want to be able to easily hand edit the input file. |
You are probably better off sticking with text mode for most everything. Reserve binary mode for special occasions.
However, I am still a bit confused about reading in text mode. |
What are you confused about, exactly?
I like the idea of a separator character to keep the fields apart, but what would be the code to read in something like that? |
That really depends on what separator you use to separate your data and the data itself. The easiest separator to deal with is the new line character (this means each field is on it's own line).
Would I read the file character by character until I saw that separator character and then skip ahead for the next field? |
Usually not, reading character by character is very slow and error prone. You would normally want to read on entire piece of data at a time.
Also, I wanted to try one other way similar to my initial example. Assuming I give an exact character length for each field that never changes, how could I read that in? |
First how are you going to write that file and insure that all the sizes are fixed. Remember reading requires something to read so work on writing the file first.
World name is 15 bytes, world width is 3, world height is 3, start area is 10:
World Name 10050 Mountains
|
Well first you need to make sure each field is the proper width. In your example "World Name" is only 10 characters (bytes). Next your width happens to be 3 in this case, but remember that means that you can only have a width of 100 to 999, is that what you envision? Next look at the height, you say it is 3 bytes but you're only showing two characters (bytes). So the first thing, if you're going to go this route, is to figure out how to write the file with the proper format.
Also, if I were to say change 100 to 200 in the program, and "Mountains" to "Plains," can that easily be written back? My current method has been reading in everything to set character array widths, then converting the arrays to numbers, then writing them back to arrays, and then writing all of the arrays back in order. |
Well look at all that conversion you have to do every time you want to read a file, seems quite complex and generally a waste of time. You really should strive to read the file once, storing the information into a data structure for continued use. Then at the end of the session (and probably other logical times) re-write the file with the current information before exiting the program.
Just as an addendum, the reason I am doing it this way is that one of my professors said that there are many legacy files and also header parts to files that are done this way, so I am trying also learn how to read and write data like this so that I may be able to work with files like that in the future, |
That may be true but if you want to learn this you really should find one of those file formats and actually try to write and read that particular format. For example a .bmp file is a good example of a binary file format that has a header and data section.