This is the mail archive of the
mailing list for the libstdc++ project.
RE: Why fixing 9533 doesn't fix 7744: revealed!
- From: Pétur Runólfsson <peturr02 at ru dot is>
- To: <libstdc++ at gcc dot gnu dot org>
- Date: Thu, 6 Mar 2003 14:55:27 -0000
- Subject: RE: Why fixing 9533 doesn't fix 7744: revealed!
Nathan Myers wrote:
> I think so. But I think it's pointless to pretend that a usable
> iostreams library can be constructed on top of the fatally
> limited FILE
For filebuf, I agree. However I don't see how sync_with_stdio()
(the default) can be made to work without using FILEs (either
using the stdio functions or using knowledge of FILE internals).
> For environments where it seems as if there's no choice
> (but, where did they get their FILEs?) we might as well use fread().
> Users there can call setbuf(0,0) if they want reasonable interactive
I don't think that would be acceptable. Better to have unbuffered
the default and provide some way to turn buffering on for those
that need it (currently, this can be done by setting a
user-defined buffer with cin.rdbuf()->pubsetbuf()).
> What was the reason that you chose a one-character buffer over making
> it entirely unbuffered? They seem equivalent, but having three modes
> seems unnecessarily complicated.
Except that unbuffered input doesn't work (PR 9024).
> > For all cases? No, but I'm willing to be shown how. If
> you can find
> > a way to unconditionally change the underlying implementation, then
> > feel free to undo all the hacks we installed to fix various corner
> > cases. (i.e. I can't disagree with Nathan's assessment.) OTOH, I
> > feel it would be a clear win to improve the
> > ios::sync_with_stdio(false) case through various means even if the
> > ios::sync_with_stdio(true) case continues to require special hacks.
> Yes, this the path forward: make the native mode fast and clean, and
> make the hack mode (just barely) work. I like the idea of two
> entirely different objects, one a hack job on stdio and the other
> purely POSIX-native, and sync_with_stdio(false) plugs the latter
> in in place of the former.
I agree. The requirements for cin/wcin in the sync_with_stdio(true)
case seem at odds with the requirements for basic_filebuf. Trying
to use a single stream buffer class for both hurts performance in
I posted such a streambuf for wcin last week:
I also tried this out for cin and it was much faster than the