The patch for PR libstdc++/14097.

[Loren James Rittle]

> Loren, first of all, thanks a lot for your turboprocessing said PR.  :-)

Well, close to major release we don't want to be the component holding
up the release... ;-)

> I have, however, a question: How is one supposed to get at the
> underlying file descriptor of an object of type
> stdio_sync_filebuf<charT>? [...]
 
Offhand, I really don't know the best answers to your questions about
obtaining the file descriptor in various cases.  I wasn't really
watching the list very closely when said changes went in...

Humm... If you refer to std::cout, std::cin, std::cerr; why don't you
just use the well-known fds 0, 1, 2?  There is nothing we can do to
stop you making that association.  However, good luck, if you attempt
to do things behind the libraries' back.

If you refer to some other library object, there is probably a good
reason we no longer expose internal details.  Many more users care
about high performance using the standard C++ way over supporting "ext
hacks" (my personal opinion based on reading all user requests).  If
you want absolute performance or control over details, then I'd invite
you to use the lowest-layer IO API available (open/write/etc).

> From a user's perspective, what the patch does, is provide a way of
> placing new stdio_filebuf<charT> objects where before have been some
> stdio_sync_filebuf<charT> objects.  For the user, that way is
> calling std::ios_base::sync_with_stdio(false).  But this just is not
> the right way!  That information should be available from the
> stdio_sync_filebuf<charT> object directly, somehow.

Sorry, can't fully parse.  We offer the ability to gain the raw fd()
in one wrapper but not the other for a reason (performance tradeoffs).

You will note that ext/stdio_sync_filebuf.h wraps FILE-level support
to sync with the libc stdio (this is a requirement of the standard in
the default mode of operation) and that ext/stdio_filebuf.h wraps
FD-level support when sync to libc stdio is not required.  We only
expose the FD when we wrap that layer.  The fact that we expose any of
this concrete detail as an extension boggles the mind...

Regards,
Loren