Thread: ios:: ??

in means open for reading. out means open for writing. binary means open in binary mode, i.e. no character transformations (like CRLF<->LF on Windows). beg means, if I'm not mistaken, to place the file pointer at the beginning, which is the default anyway.

also, how can i get the program to display the values that were last inputted to the file when the program was last opened?

You can't. You will have a text file, and that's all you know. You will not know whether that file has been written to 100 times or only once.

You could put a special character in the file at the end of every write or leave a blank line after each write, which would server to delineate the separate chunks of output that have been written to the file. Then you can read in the whole file and examine just the last chunk of data.

binary means open in binary mode, i.e. no character transformations (like CRLF<->LF on Windows).

As I understand it, C++ guarantees that line feeds in a text file:

Windows: \r\n
Mac: \r
Unix: \n

will be converted to '\n'. So, does opening a file in binary mode tell C++ not to make those conversions? My book has a statement that I've never understood. It says:

Using Binary Mode Stream Operations

There are situations where text mode is not appropriate or convenient, and it can sometimes cause you difficulties. The transformation of newline characters into two characters on some systems and not others makes relative seek operations unreliable for programs that are run in both environments. By using binary mode, you avoid these complications and make your stream operations much simpler.

But that seems to suggest that binary mode "sees" the same thing for all systems, and therefore that all newlines are converted to '\n' in binary mode.

No conversions of any kind are done in binary mode. That means that if the file on disk contains \r\n, the memory will contain \r\n after reading, too. Similarly, if the memory contains \n, then the file will contain \n too, even on Windows and Mac.
Binary mode is made for, wait for it, binary data like images, where such conversions would merely mess up the data. (For example, the first few bytes of a PNG contain both \n and \r\n, to detect such conversion errors.)

The implication that binary mode sees the same thing is not really there, although I see how it could be understood that way. For the in-memory representation of text to be reliable across systems, you need the on-disk representation to be reliable, too. By the way, this goes for text-mode files too - load a Mac file in Unix and you've got the wrong endings, even in text mode. And to make matters worse, a Win32 EDIT control wants the in-memory representation to contain \r\n. (Load a Unix text file in Notepad.)

The implication that binary mode sees the same thing is not really there, although I see how it could be understood that way.

How? It seems quite clear to me now that binary doesn't see the same thing in a text file that has been created on different systems, and therefore the quote I posted is erroneous. In particular, a seek operation is done on a file that is already written, so using binary mode won't work on a text file that was created on different systems because you don't know how many characters are in a newline.

Hmmm...maybe that quote is talking about writing a '\n' to a file. If you write it in text mode, does that automatically get converted to "\r\n" on Windows when it is written? If so, then the quote may make sense because if you write in binary mode, you will write a '\n' to the file on all systems, and therefore you know only one character is there, and therefore you can perform relative seeks and you will be at the same position in a file on all systems.

Yes, it gets converted. The quote is only talking about the files your program handles privately. If your program creates a file in binary mode, it can reliably seek within, because there won't be any unexpected changes.