PATCH: fix portability for ext/stdio_filebuf/char/10063-2.cc
Pétur Runólfsson
peturr02@ru.is
Tue Jan 20 21:46:00 GMT 2004
Paolo Carlini wrote:
> Clearly, stdio_sync_filebuf works well, Pétur designed it exactly for that
> purpose!,
Yep. This was actually true in two different ways. It's better than
stdio_filebuf was (it's faster, and supports wide streams); and by
replacing stdio_filebuf as the stream buffer for cin, it became
possible to break stdio_filebuf without breaking conforming programs.
> that's not the point of the PR...
The point of the PR was mostly this blurb from
http://gcc.gnu.org/onlinedocs/libstdc++/27_io/howto.html#11
Today the recommended way to use stdio types with libstdc++-v3
IOStreams is via the stdio_filebuf class (see below),
but this wasn't (and apparently isn't...) a very good idea.
> My strictly personal opinion is that for 3_4 we should make of
> stdio_filebuf.h
> an internal header, differently named indeed, and not available anymore
> in /ext. That seems to me the only clean and consistent solution. As you
> read in the trail, Pétur agrees.
At least the documentation should be changed to mention that
stdio_filebuf doesn't work as well as it did in previous versions.
I'm not sure if stdio_sync_filebuf should be recommended as a
replacement (in case it needs to be changed). At least
stdio_sync_filebuf shouldn't be renamed to stdio_filebuf, because
the interface is quite different (it lacks open, is_open, close, fd
and the constructor taking a file descriptor) and provides very
different services (wide streams are supported through wide versions
of stdio functions instead of codecvt, it doesn't do buffering).
Maybe users who want to wrap stdio with iostreams should be told
to write their own streambuf; it's not that hard ;-)
Regards,
Petur
More information about the Libstdc++
mailing list