Re: Visual C++ 2005 basic_istream::get(buf, size, delim) bug?
denise.kleingeist@googlemail.com wrote:
Terry G wrote:
Here's a seemingly simple program that doesn't work using
Visual C++ 2005, but g++ 3.4.4 works as expected.
I'd say it is exectly the other way around. Of course, my
expectation takes the standard into account rather than
wishful thinking. That is, the first behavior is correct, the
second wrong - assuming that both implementations indeed use
the same end of line sequence: if there is actually a CR/LF
sequence at the end of the line, both implementations can be
conceivably correct.
Formally speaking, both could be correct no matter what. It's
implementation defined what the implementation considers "end of
line".
In practice, I'd say that quality of implementation requires
that the usual conventions for the system be respected: an
implementation under Windows which considers the byte sequence
0x0d, 0x0a as a '\r' character, followed by a line separator (or
terminator---I'm not sure which CRLF is supposed to be under
Windows) is just as wrong as an implementation under Unix which
requires the two bytes. As far as the standard goes, if they've
documented the behavior as such, they are "correct", but from a
quality of implementation point of view...
Some implementations may accept additional sequences: at least
one Unix based implementation I know will accept either CRLF or
just LF as a line terminator. (Under Unix, the convention is
clear, and the LF is a terminator, and not a separator.) I'd
say that there's no problem with the quality of implementation
there, as long as they do accept the usual terminator (and they
are being "reasonable", of course---accepting the sequence
's',LF as a terminator, and replacing it with a single '\n'
would not be reasonable, IMHO, whereas accepting CR,LF is).
Perhaps I wandered into "undefined" territory somewhere.
Nope: all well defined (well, if you discount the minor detail
of not including <istream> as is, strictly speaking, required
by the standard to get a definition of any of the stream
classes rather than just the declaration of the 8 standad
stream objects <iostream> is providing).
==================================
File: try_get.cpp
==================================
#include <iostream>
#include <limits>
For the above line, get(Line, sizeof(Line), '\n') will not store any
characters and thus set failbit.
Unless, of course, the line contained some trailing spaces we
can't see:-).
If the line is terminated by a CR/LF sequence, this will be
transformed into a '\n' character on Windows aware systems but
become a "\r\n" sequence on non-Windows systems, thus storing
one character ('\r') and not setting failbit.
Implementation defined, and at least one Unix system does accept
CRLF as a line terminator. (At least, that's what one of the
authors of the compiler told me; I've never tried it.) Also,
most Windows implementations will also treat a solitary LF as a
line separator (or terminator). (At least, those I've tested
all do. Since I maintain my files on Unix systems, my Windows
code does have to deal with isolated LF's, and I've never had a
problem with it in code I've compiled myself.)
I would consider both approaches to CR/LF handling to be valid
since the standard is silence about the details how std::cin
is implemented. In particular, it does not spell out that it
has to use a std::filebuf and if so whether it use text or
binary mode: the CR/LF -> '\n' is only recommended for
std::filebuf in text mode.
I think you're talking about the compiler here. The standard
does require that std::cin be open in text mode. (At least, the
C standard required this of stdin. I can't imagine C++ being
different in this regard, but I'm too lazy to look it up.)
I think we really should take quality of implementation issues
into account, too. As far as the standard is concerned, an
implementation could define '@' as the line terminator; in which
case, his whole file would be a single, unterminated line, which
the implementation is then free to ignore. I wouldn't use such
an implementation, of course, and I suspect that I'm not alone.
int main() {
static char Line[1024];
while (std::cin.get(Line, sizeof(Line), '\n')) {
std::cin.ignore(std::numeric_limits<int>::max(), '\n');
Note that the above line will always extract at most one
character! Only if the call to get() already hit EOF without
failing (e.g. because the last line is not properly terminated
by an end of line character) the above line might extract a
different number of character than one: in this case it would
extract no characters. See 27.6.1.3
(lib.istream.unformatted)/8-9 and /24-25 for details.
What happens if the program encounters a line of more than 1023
characters?
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]