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 Wed, 14 Feb 2001, Theodore Papadopoulo wrote:
> 
> 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.

The ISO Standard C library provides the platform-independant stdio I/O facility, aka fopen() et al.  The stdio
facility provides a platform-independant abstraction that has allowed an amazing degree of software portability. 
Various vendors have added OS- or platform-specific extensions, but reliance on them does break code during
cross-platform ports.

The ISO Standard C++ library, while including stdio for backward compatibility with legacy code, provides the
IOStreams facility for performing the same function.  IOStreams and stdio are at the same "level, " and nothing
prevents one from being implemented using the other (yes, there is some bletcheration about cin/cout/cerr being tied
to stdin/stdout/stderr, but those are special cases).

Most OSes, well all OSes that I'm aware of, provide some sort of I/O facility on which both stdio and IOStreams must
be built.  For Unix and it's Posix descendants, there are the unistd kernel calls open() et al. which return an "int"
file descriptor (as oppesed to the FILE* handle of stdio).  This is similar in nature to the MS-DOS open() call, the
Atari TOS Open() call, and a host of others.  It is not similar to the Macintosh PBOpenF() with its PB structure, or
the VAX/VMS calls that fill in FAB, RAB and XAB structures, or whatever nefarious evil is propagated in OS/360.  I'm
not an expert, but I suspect a number of embedded systems may not match Posix functionality either.

GCC is a cross-platform tool, not a Posix tool.  GCC has contributed to the spread of computers and the internet
more than anything else in existence (I would argue) and part of that is because of the great effort to keep it
portable.  By enshrining platform-specific extensions as a part of its distribution, that would no longer be the case.

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.


Stephen M. Webb