Newlinegreenspun.com : LUSENET : Steve Heller's books : One Thread
I seem to be writing you a lot today. Another question came to mind that's been kicking around since the end of the first C++ book. This threw me at the end of the last chapter and is about the only thing I'm uncertain of from that material.
What is a newline character? I looked all through an ASCII table looking for it but didn't find anything. I concluded that it wasn't an ASCII character at all, and then just resigned myself to that it was something I'd run into eventually.
In programming in this language, it's represented by "\n" and you also refer to it as an end-of-line character. However, as written in the code, it isn't a sole character, but rather two characters. You say that this "peek()" function looks at the next character in the input stream to determine if it is a newline or not. Well, what exactly is it looking for? As you say, this is only an issue reading in from a file with mixed types, as the user hitting return on the keyboard gives the "newline" automatically. But what does this look like in a file on the disk? If "peek()" is looking at the next character, then it would interpret whatever value it finds as one of the 256 characters of the ASCII code, right? So does that mean that one of those characters has been, in C++, redefined to represent the end of the line? And, does the compiler make an executable that inserts that newline character after every single variable it writes to a file, thus making it detectable by the >> operator implemented in your book?
Or is this newline char the same as a null byte? This could make sense if the executables from C++ all wrote this null byte at the end of every variable it put in a file on disk. But then how would a program looking at your inventory file distinguish between the end of one Stockitem and the beginning of the next? And, for that matter, I've been wondering how it does that under the current setup anyways. I mean, how does it look at the file and determine 1.not only where they begin and end, but also 2.which string belongs to which variable and which numeric value belongs to which numeric variable. Is all this information embedded in the file by our program? Looking at the files in a text editor doesn't reveal any monkey business I can't account for.
Does this then mean that the input function for the Stockitem class assigns them in the same order that the function that wrote them puts them out, and that one needs to ensure that the same order is maintained for the variables in both lest you end up reading in the m_Distributor as "43", for example?
The above represents, really, the last uncertainties I have thus far. Happily, I did buy that IOStreams Handbook by Steve Teale, which you referenced in the first book. Hopefully, when I'm up to where I can read it (not yet - I glanced through it) this should emancipate you from these niggling questions on input and output. Until then, the above are the questions that keep me up at night. Thanks again for your help.
-- Mike Mannakee (B3FEETBACK@aol.com), May 09, 1999
It is represented by either one or two characters in a file, depending on the operating system under which the program is running. Under DOS, it is represented by a "carriage return" (ascii 13) followed by a "line feed" (ascii 10), while under Unix it is represented by just a line feed character. The names of these characters are historical artifacts from the era of teletypewriters. <>"\n" actually is the name of the newline character, no matter which representation it is written in. You can also write "\t" for a tab character or "\b" for a space character, but those are again names of single characters.
To put a newline in a file, we write it explicitly by using the "\n" or "endl".
It is definitely not a null byte. Null bytes can't be read by normal C input functions, again for historical reasons.
Yes, the input function for the Stockitem class assigns them in the same order that the function that wrote them puts them out, and we need to ensure that the same order is maintained for the variables in both.
-- Steve Heller (firstname.lastname@example.org), May 09, 1999.