Re: Accessing the underlying file descriptor in fstream

[Gabriel Dos Reis <gdr at codesourcery dot com>]

Theodore Papadopoulo <Theodore.Papadopoulo@sophia.inria.fr> writes:

| [1  <text/plain; us-ascii (7bit)>]
| 
| 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. 

That is not the question under discussion.

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

Well, it is not a QoI.
It is a matter of extension with a far reaching impact on the whole
implementation.  Maybe you might want to study other implementai

[...]

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

It IS temporary.

You might want to take a look at popular IOStream implementations
around, such as those designed by Matt Austern, Dietmar et al to have
an idea of what the issues are.

Certainly, something has to be done, but FILE* doesn't seem to be
popular in reasonable IOStream implementations.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com