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

[Jon Cast]

Gabriel Dos Reis writes:
> Jon Cast <jcast@ou.edu> writes:
>
> | 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.
>
> No, you get it wrong.
>
> A code perfectly well-defined under C/Unix will continue to be
> perfectly well-defined under C++/Unix. Nothing is broken.
>

Notice I said "without sacrificing the major advantages of C++ for I/O."
stdio and FILE*s work great for C, but in C++ they don't fit.  C++ is
type-safe, type-overloadable, etc.  Stdio isn't.  So what I saying is, a
certain *paradigm* that is legal C (use high-level code where you can,
descend to lower levels when necessary) should also be available in C++.
FILE*s are incredibly primitive compared to iostream.  So using them hardly
qualifies, IMAO, as `high-level'.  Therefore, code that uses fileno in C++
has a different relation to the surrounding language than it would in C.
It's well-defined, just like printf is well-defined.  But nobody suggests
using printf in C++ is a good idea.

If ANSI C specified some feature that was useful, and commonly used, and
ANSI C++ didn't provide a type-safe, etc. version, that would be a bug.
Well, Unix C (and this includes glibc) provides a useful and commonly used
feature.  Unix C++ should provide a type-safe version.

Jon Cast