Re: Accessing the underlying file descriptor in fstream

[Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>]

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
 --------------------------------------------------------------------

PGP signature