Date: Sun, 15 Nov 1998 13:15:28 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: sl <sl AT psycode DOT com>
cc: "djgpp AT delorie DOT com" <djgpp AT delorie DOT com>
Subject: Re: gcc v281 bug?
In-Reply-To: <fycflpbqrpbz.f2c2cj0.pminews@nntp.generation.net>
Message-ID: <Pine.SUN.3.91.981115131504.1381W-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com


On Thu, 12 Nov 1998, sl wrote:

> 	Speaking of which, under the new C++ standard many buffer-dependant
> commands are now required to flush all output when attempting to input
> something from the other (in order to make sure that the prompt is displayed
> before input is expected.) Makes perfect sense to me

Not necessarily so.  Input and output doesn't have to be connected to
each other: think about the case where stdout was redirected to a file.

> Is this expected to be handled by the next GCC release?

It's a library issue, and so it has nothing to do with the compiler.
If the C++ standard requires this, the C++ library should work like
this.

In any case, please note that mixing `putch' with cin and such likes
will most probably not solved even under the new C++ standard, since
`putch' is not described by any standard.  In fact, `putch' doesn't
even do any I/O in the usual sense, since it writes directly to the
video memory.  I can easily imagine people who use `putch' for fast
display to object to the idea of having their code slowed down by
flushing output streams every time they need to put another character
on screen.