Accessing the underlying file descriptor in fstream
Theodore Papadopoulo
Theodore.Papadopoulo@sophia.inria.fr
Wed Feb 14 02:11:00 GMT 2001
gdr@codesourcery.com said:
> Kevin Atkinson <kevina@users.sourceforge.net> writes:
> | About a year ago I asked about if libstdc++ will provide a way to access
> | the underlying file descriptor in the fstream class.
> That question assumes that our libstdc++ IOStream facilities *should*
> be FILE*-based, which we already debated in the past as not to be a
> viable assumption.
Sorry, I disagree slightly...
I do not have a recent C standard handy (my K&R book is an old pre 89
book) so may be I will get it wrong but I seem to remember that at least one
of the two variants of open or fopen is standardized in C. Delivering
an extension of the library that allows interoperation between
streams and the C library or the system is a matter of quality of implementation
IMHO. I can see three possible variants:
1) return an id a la open.
2) return a file descriptor FILE* a la fopen (which should always be possible even if stream
are not FILE based), after all even if there are based on a libio or
on open, there ought to be functions that generate FILE* from
whatever is used.
3) Return whatever is used in the stream library and let the user
deal with the result. This is certainly the easiest thing, but there
are portability issues. stream ARE now based on FILE* AFAIK but
this is only temporary, right ?
My preference goes to whatever solution is standardized in C. 1) and
2) are equivalent to me since often (if not always) there are functions
doing the conversions between the two (fileno and fopen for linux).
Not everything is possible with the stream library and a lot of code
out there is available with the FILE* interface (and at least all
Unix systems use the int a la open). I, for myself, had
postponed some development because of the lack of memory mapping (Yes,
I know this is dangerous, you told me that but for the application I
have in mind it makes a huge improvement).
So please consider adding something, whatever it is, to ease system/C/C++
integration.
Theo.
--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
--------------------------------------------------------------------
--
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.2 06/23/2000
iD8DBQE6ilmxIzTj8qrxOU4RAlROAKCzOvvCpopnrkdYe9pSTC404SUDwQCg0a42
A+fwuXlxwgL2AgjWr8dl2Pk=
=66oZ
-----END PGP SIGNATURE-----
More information about the Libstdc++
mailing list