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

[stephen dot webb at cybersafe dot com]

On Thu, 15 Feb 2001, Jon Cast wrote:
>
> In C the underlying mechanism of a FILE* _is_ available, in practice even if
> not in theory.  So what you're saying is, code that is perfectly
> well-defined under C/Unix should not be possible under C++/Unix without
> sacrificing the major advantages of C++ for I/O.  That, IMAO, is a
> legitimate QOI issue, not some essential sacrifice to the dread god of
> `portability'.
> 
> If your concern is for abstraction, then I would say this is an area where
> ease of use trumps abstraction.  It isn't any good to abstract your
> interface to the point of breaking well-defined and useful code.  That kind
> of code, if it became prevalent, would be asking for a fork.

In C++, the stdio abstraction is completely available and according to the ISO standard continues to be supported. 
In addition, the IOStreams abstraction is also available.  The two abstractions are orthogonal.  They are also
philosophically very different.

The originating problem of this thread arose because of a desire to intersect the two abstractions in non-orthogonal
ways.  There is no easy way to do this. If a developer wants to make this easier by having her tools work in ways
that contravene their own design philosophy, she will meet with a lot of resistance.

The example of trying to use OS-specific calls (eg. mmap()) on OS-specific entities (eg. file descriptors of
previously opened files) IS covered by standard-conformant application of the IOStreams library.  You simply write
your own streambuf class modeled after the fstreambuf to wrap your mmap, passing its open() member your file handle or
file descriptor, and write your own iostream derived from basic_iostream to insert and extract data.  Easy to do, and
doesn't require your tool implementors to expose the dark and unspeakable horror of their implementation (sorry,
guys, it just seemed less worn than 'black box').  You can also guarantee that only the implementation of your
streambuf would need to change for a port to a non-Unix platform, and nothing else.  That's where abstraction turns
out to be colinear with ease of use, and your sacrifice to portability gives you a great big tax deduction.

If a programmer doesn't want to go to the trouble of creating his own IOStreams to provide custom functionality
within the framework of the entire IOStreams mech, he can feel free to continue to use the stdio mech in full
confidence that he is C++ standard conformant.  If he wants to take advantage of IOStreams, the onus on him to use
the tool as it was designed rather than have the tool change to cut a corner andf lose its effectiveness.


Stephen M. Webb