Getting a file descriptor or a file number) for an fstream (Was: Accessing the underlying file descriptor in fstream)

[Theodore Papadopoulo]

stephen.webb@cybersafe.com said:
>> Thus, if it is possible to implement the feature (and I think it is), 
>> let's keep it as simple as possible, make no promise and clearly 
>> state that it is an extension (eventually, activate it 
>> only with a special flag). Last, if full portability cannot be 
>> achieved keep it conditionnal to the system, althought I'd prefer not 
>> going that direction.

> You're asking for OS-specific functionality to be added into the
> standard, non-OS-specific library.  It is not a Good Idea. 

Re-read my E-mail, it is a plea for doing it using the ANSI C 
standard (POSIX is mentionned only if ANSI is REALLY not possible).
ANSI C is certainly not tied to an OS.

That last sentence repeated above is just in case it is really not possible
"IF FULL PORTABILITY CANNOT BE ACHIEVED". I prefer having something that works
almost everywhere than nothing. I might not have added that, but 
having a way to do file operations on the OS level is important.
All the implementations I know of stdio give a function similar to 
fileno to be able to do such a thing.

My preference clearly would be to have a method that returns a FILE* 
corresponding to the stream. As I said in my E-mail, I believe this 
is always possible (regardless of some problems about seamless 
integration during concurrent uses of both FILE* and streams).
And this is portable. Everything else can usually be done from this
simple information.

> If the problem is that you need to extend the IOStreams library with platform specific functionality
> (such as Posix file locking), the Wrong thing to do is to change the standard library.  The Right thing
> to do is to write your own streambuf which would invoke the extended function at the proper time.
> It's not hard, it's not particularly
> inefficient, it's as portable as its underlying assumptions, it's elegant, and it's the C++ Way.

> Extending IOStreams whould be your first choice, not extending the language.

Well, this is true unless I have no control on the person that opened 
the file which is often the case.

To me, it is so evident that every one will one day or the other 
want to do some very specific file operation allowed by the operating system on a file
opened with a stream (file locking, memory mapping, getting creation 
or modification dates, ...). The most natural way to do it (and most simple too) 
is to provide something that give access to the OS level description 
of the file. But that's non portable, oh but FILE* are and are 
convertible to OS-dependent things if necessary...

Now, of course, if someone comes tomorrow (not in ten years) with a 
standard specifying a clean nice standard interface for doing all you 
have ever wanted (and will ever want to do) to do on file on any OSes
of the universe (future, past and present), I'll adopt it immediately. 
:-)

Up to then, I prefer something simple that has a chance to work for 
everyone and that is as portable as possible.

I just hope that I'm not unclear...

	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

iD8DBQE6irCHIzTj8qrxOU4RAokmAKCgMLFMO3+Y/wX4KE+zMVGxxqXLtQCfcms1
WgFFPQMJUDqSmmaSYYpxANA=
=EWNA
-----END PGP SIGNATURE-----