GNU extensions
Scott Johnston
scott@accom.com
Wed Jun 20 13:32:00 GMT 2001
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
More information about the Libstdc++
mailing list