Re: "inFile" object cannot read EOF
On Jun 8, 10:42 pm, "BobR" <removeBadB...@worldnet.att.net> wrote:
Victor Bazarov wrote in message...
BobR wrote:
James Kanze wrote in message...
** You can't "read" EOF **, since by definition, a read fails if the
file is at EOF.
So, my docs are wrong?
" Method: int istream::get ()
Read a single character ** (or EOF) ** from the input stream,
returning it (coerced to an unsigned char) as the result. "
Whoever wrote that decided to shorten it a bit. What it should say
is "Read a single character from the input stream returning it, or
return a special value if the stream is in 'end-of-file' state".
Ok, I'll buy that. Thanks.
The important point is that at this level, EOF is an out of band
value, and not a character. At this level, because...
In fact, istream::get() returns either the character it read or
'traits::eof()', according to the Standard. It doesn't "read" any
"EOF" from the stream.
No "implementation defined" escape clause there? I'll check it
out (for my systems(win,GNU)) to satisfy my curiosity <G>.
Most of what takes place in IO is more or less "implementation
defined". When it's not flattly unspecified In particular, how
an implementation represents line breaks and end of file is
unspecified, and may (and does under most systems) differ
between text files and binary. (For Unix, everything is pretty
much transparent, and there is no EOF character, either in text
or in binary files. I think that most Windows compilers,
however, still recognize the traditional CP/M end of file
character, 0x1A, in text files.)
Note that historically, a common error was writing the result of
istream::get() or istream::peek() (or earlier, getc() or
getchar()) to a char, and testing that for EOF (typically -1,
although any negative value is legal). This worked if (and only
if) plain char was signed, and the file never contained a 0xFF.
In ISO 8859-1, 0xFF is the '=FF' character (small Latin letter y
with diarese, if it doesn't show up right here). Not the most
common character, so the error often went unobserved.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34