On Oct 7, 11:34 pm, Gianni Mariani <gi3nos...@mariani.wswrote:
john wrote:
James Kanze wrote:
other implementations (e.g. g++) simply treat
the sync as a no-op.
I am not sure what you mean by this. I am using g++ under Linux and it
doesn't complain for "cin.sync()".
I'm not sure either since the strace I showed earlier is from a Linux
system. However don't expect your compiler to complain if somthing is
implemented as a no-op.
The g++ behavior seems to depend on the system; I get different
behavior under Solaris and Linux. IMHO, it would also be
reasonable for the behavior to be what you describe if the input
is from a regular file, but to be a no-op is isatty is true, or
if the input is from a pipe (named---since I don't think the
current implementation of g++ has any means of getting an
istream from a pipe).
At any rate, the behavior is definitely variable; if I do
something like:
std::cin >aChar ;
std::cin.rdbuf()->pubsync() ;
std::cin >aString ;
then input "abcd<RETURN>123", followed by a return and the
system end of file character (^D under Unix, ^Z under Windows),
I'll get "bcd" in aString on some implementations (Sun
CC/Solaris, g++/Linux), "123" on others
(g++/Solaris,VC++/Windows). IIRC, "123" corresponds to the
traditional implementation; what the classical iostream from USL
did. (And of course, a lot of Windows programmers think that
that's what it always does, because that's what VC++ does.)
For a tty, of course. If I put the same data in a file, and
redirect input from that, I get something different with
g++/Solaris and VC++/Windows: "bcd" with g++/Solaris and an
empty string with VC++. The only way I can explain the g++
behavior in this case is that the implementation detects if the
input is a regular file (or not a tty, or something), and
behaves differently. (A very reasonable choice, thinking about
it. Seek back the number of characters in your buffer and throw
out the contents of the buffer if seeking will work; no-op if it
won't. But why don't I get this under Linux, then? My Solaris
and my Linux version were generated from the exact same source
tree.) VC++'s behavior, of course, is exactly what you get by
just throwing out any contents---keyboard input is line buffered
by the system, so you throw out through the end of the line,
file input isn't, so you throw out (in this case) a lot more.
Anyway, I think we agree that there's nothing here you can count
on in portable code.
--
James Kanze (GABI Software) email:ja*********@gmail.com
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