This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Accessing the UNIX file descriptor inside an fstream
- To: libstdc++ at gcc dot gnu dot org
- Subject: Re: Accessing the UNIX file descriptor inside an fstream
- From: Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>
- Date: Tue, 18 Sep 2001 19:05:39 +0200
I'm really happy to see that the idea of giving access (in some way)
to the file descriptor corresponding to a stream seems to be better accepted...
ncm@nospam.cantrip.org said:
> The Standard doesn't in any way imply that filebuf is built on top of
> a C library FILE*, and I would hate to see the library documenting
> such a dependency. The file descriptor, OTOH, is ultimately necessary
> to implement filebuf on a POSIX system, so providing access to it
> creates no new dependencies. I would also welcome a way to bind a
> filebuf to an existing file descriptor (of course such a constructor
> must be marked "explicit").
On the other end, the notion of file descriptor does not exist in
Standard C. I would find much more clean to return a FILE* which is
the standard way of describing an opened file in standard C. This way
the burden to rely on the "non portable" (up to my knowledge) function
fileno to the user and we have something that is coherent with the C
standard. Note that I do not believe that this incurs that the stream C++
library is built on the top of FILE* as it seems possible to build a FILE*
from a file descriptor (fdopen) or the underlying libio object (one
day).
> Aside from dependency issues, building in automatic conversions is
> almost always a mistake, and would certainly be a mistake in this
> case. Ordinary members are the right way to do this.
> If, in addition to filebuf<>::fd(), somebody wanted to add a patch for
> a filebuf<>::_libc_FILE_pointer() documented as unsupported, I would
> not object.
I would prefer giving the method a better name and protecting it by an
#ifdef GNU_NON_SUPPORTED_EXTENSION
#endif
that would explicitely show that the thing is not Standard C++,
unsupported and require some action to be made available.
Theo.
--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
--------------------------------------------------------------------
PGP signature