On Oct 6, 1:58 pm, john <j...@no.spam> wrote:
> I am reading TC++PL3 and on page 644 it is mentioned:

> "Flushing an istream is done using sync(). This cannot always be done
> right. For some kinds of streams, we would have to reread characters
> from the real source - and that is not always possible or desirable.
> Consequently, sync() returns 0 if it succeeded. If it failed, it sets
> ios_base::badbit (21.3.3) and returns -1. Again, setting badbit might
> trigger an exception (21.3.6). A sync() on a buffer attached to an
> ostream flushes the buffer to output".

> So, what exactly should we expect from an call of sync() on an istream?

Nothing. The standard leaves it entirely up to the
implementation; different implementations do different things.

> Making its streambuf to lose all its contents?

Well, it certainly depends on the type of the streambuf; for a
stringbuf, for example, sync is always a no-op. For a file buf,
sync() on input isn't specified by the standard.

Some implementations, I think, simply throw out any data they
happen to have in the buffer. *IF* the implementation is line
buffering the file (as do Unix, and I think Windows, when the
data source is a keyboard), this has more or less the same
effect as ignoring input up to and including the next newline.
Don't use it for this, however, since it will fail if the input
is not line buffered (not from the keyboard). And of course,
it's not standard; other implementations (e.g. g++) simply treat
the sync as a no-op.

--
James Kanze (GABI Software) email:james.kanze@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