This is the mail archive of the
mailing list for the libstdc++ project.
Re: PATCH for libstdc++/2211 (some discussion held on gcc-bugs)
- To: libstdc++ at gcc dot gnu dot org
- Subject: Re: PATCH for libstdc++/2211 (some discussion held on gcc-bugs)
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- Date: Sat, 30 Jun 2001 03:10:43 -0500 (CDT)
- CC: Theodore dot Papadopoulo at sophia dot inria dot fr
- Reply-to: rittle at labs dot mot dot com
> In my opinion, only hosts that want to be able to use ungetc/getc in
> place of fseek() within underflow() force a requirement that an
> input buffer attached to cin be of size 1 without regard to whether
> we are synchronized with C IO or not. [...] The attached patch
> matches this level of my thinking on the matter.
Here is the next level of thinking on this matter (without any patch):
In the case where we are unsynchronized with C IO, why are we
repositioning the IO stream pointer at all (this translates directly
to kernel calls that retard performance)? What section of the
standard mandates this? If we don't need to reposition the IO stream
pointer within underflow() when we are unsynchronized with C IO (and
there is some adequate way to learn when we are not so synchronized),
then all platforms could use the larger buffer size without causing
problems for interactive test cases.
After thinking about this issue for a while (over the course of months
not just this report and gcc-bugs follow-up discussion): It would be
awfully nice (although somewhat of a major internal architectural
change) to be able to disconnect the concept of buffer size and
"optimal take size for the current situation". In particular, this
architecture would allow us to always attach a BUFSIZ buffer at the
C++ IO layer but in any case where we are scanning the input stream
for a value that may need to be put back (i.e. to synchronize with C
IO since we didn't eat it, etc.), we take only 1 character at a time.
When a request is coming through the C++ abstraction layer for a set
number of characters (i.e. by explicit read() method call), then we
refill a full buffer size at a time (or up to the requested size).
The standard mandates that underflow() return the next character from
a real input source. I see nothing that says it must completely fill
the buffer area.