Re: filebuf::fd()

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

ncm-nospam@cantrip.org said:
> It's trivial to write that.  But that's not the point.  The problem is
> that it commits us to constraining our filebuf to have stdio
> implementation and semantics underneath. 

> The right way to implement this, on a mature target, is for the  FILE
> struct to contain or be derived from a filebuf<char>.  In that  case
> there's no FILE* to return. 

No, no, no....
The function can return whatever it wants and do internal something 
else. The library call fdopen is here for that.

Let me summarize and clarify the discussion here:

1) People would like to have access to a more basic object than the
filebuf. The reason for this is to get the full services provided by 
the OS, which up to now is mostly file descriptor based.

2) I have heard of some possible long term plans to provide a POSIX
kind of C++ binding. I deliberately use fuzzy words here since I do 
not know what are the exact plans nor if this is more than just an 
idea in the air. The KEYPOINT is that this will certainly not be
available soon (if it is ever). In the meantime, it would be nice to 
have something to have better integration between C++ and the OS.

3) Disregarding the implementation, there are two choices:

	- FILE based approach. FILE's are in the C standard
          (and thus likely to be there with every C implementation
          including PDA or real time platform IMHO). Since the C++
	  standard is insisting in keeping the compatibility with
          standard C (well at least before C99), this militates in
          favor of this choice.

	- int (file descriptor) based operation, which is in the POSIX
          standard. Adopting this is clearly in line with the presumed
          intent (see above, all disclaimer about still apply) of the
          future extension of the C++ library. On the other hand,
          POSIX is a biding standard, which is very different from a
	  language standard, and not necessarily adopted by all the 
          operating systems, which potentially creates a portability
          problem that has to be reviewed carefully.

4) On the implementation side:

	Whatever is the choice (int or FILE*) of the type we decide
	to return, the constraint on the implementation is the same.
	The function fdopen and fileno are usually here to assert that
        if one can be done the other one can be done too. Note that
	only fdopen is POSIX, though whereas fileno is not. Since libio
        is used to implement open, fopen or the future filebuf, I might
        be naive but I do not see a major reason why building a file descriptor
        or a  FILE* from the underlying libio structures would not be 
        possible. Neither one solution or the other between FILE and
        file descriptor is worse in this regard.

	BUT THE TYPE RETURNED IS INDEPENDANT OF THE INTERNAL IMPLEMENTATION.

5) The choice is political:

	Indeed, even if I have a FILE, in most of the case my first 
        step will be to get a file descriptor with fileno (since
	most of what I want to do is memory mapping, file property 
        manipulation and stuff like that). My need for a a "raw
	file access" is POSIX.

	+ in my opinion, FILE is more in the spirit of the standard
          as we have now (C compatiblity and easy mix of C and C++).

	+ file descriptor, might be more in the spirit of a future
	  standard (but if there is a POSIX C++ binding, I'd expect
	  to have details like file descriptors completely disappear).

	Note a final difference:

	+ Using FILE would oblige the user to use the non POSIX, non
          standard C (I rely on linux man here) fileno function.

6) Other things that might influence the choice:

	+ What can be easily be done on non libio platforms (windows,
          real time embeded platforms, PDA, ....).

	+ What has potentially been done already by other C++ 
          standard library implementors...

As for the solution of implementing FILE with a filebuf<char>, I'd 
like to see it one day, but I'm not very optimistic since that would
potentially draw quite some piece of C++ in the C world...  ;-)


	Theo.
 
--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Attachment: msg00047/pgp00000.pgp
Description: PGP signature