Re: GNU extensions

[Scott Johnston <scott at accom dot com>]

The fdbuf/ofdstream example submitted by Carlo Wood is useful, but has
problems.  Specifically any call to ostream::put disables subsequent
output on the stream for some reason (i.e. fdbuf::overflow is never
invoked again).  The workaround is to exclusively use the "<<" operator.

Does anybody have equivalent code for an fd-based istream.  Would it be
as simple as adding an underflow method to fdbuf, and creating an
ifdstream class to hold the fd?

I've determined that the filebuf(FILE*) extension doesn't work for
reading from sockets.  I'm prepared to rewrite all my socket istream
code the old-fashioned way (with read(2)), but...

I still believe a filebuf::attach method (added into libstdc++ v3) would
be a great boon to existing C++ software.  I've read all the arguments
against the use of "non-standard" file descriptors in portable code, but
I'm not buying it.  By inspecting the extremely portable ACE library
(http://www.cs.wustl.edu/~schmidt/ACE.html) I see that most  every OS in
the world treats sockets and file descriptors the same (with integer
descriptors that can be passed toread/write), except for a Win32
OS where you need to handle them separately.

So a portable way of using file descriptors in a filebuf constructor
would be to have different constructors for sockets and normal file
descriptors.  I would be happy with that.  Yes it would be non-standard,
but it would be backward compatible (a greater good). Why all the
concern (in the GNU world) for conforming to ANSI C++ anyways, the
document itself which is decidedly non-free?

Scott Johnston
http://www.ivtools.org