Re: Accessing the UNIX file descriptor inside an fstream

[Chris Rankin <rankinc at pacbell dot net>]

> Sure it can.  It's just that the member function you want is in a base
> class, and it's hidden.  Use the scope resolution operator to expose it.

Aha. It was hidden in the basement, in a cupboard with a sign on it's
door saying "Beware of the leopard!"...

> Note the use of the non-standard ctor.  Does this help?
> 
> Note also that filebuf member functions tend to behave very strangely
> after doing an end-run around the derived rdbuf() like this.

Oh. That's no good then, is it? How can I use a function that may or
may not cause my program to explode?

> > Nor
> > do the internal workings of the libstdc++ IO-streams appear to be
> > documented interfaces,
> 
> Well... yeah.  I don't want to come off as a smartass, but they are
> internal workings, not public interfaces.  They will be documented as soon
> as somebody volunteers to do so, or pays somebody else who has time to do so.

The flipside of this is that therefore you can't honestly expect
anyone to extend the base classes to add any extra functionality. Such
work would almost certainly be wasted at the next compiler upgrade.

> 0)  Nobody is arguing against adding extensions.  But we are trying to
> get the library -- the standardized part, mind you -- finished and working
> before we start adding cool bits.

Unfortunately, until that happens libstdc++ doesn't have enough
functionality for me to use.

> 1)  Once extensions are in, they are damn hard to get rid of, should they
> prove to be a bad idea, or not well thought-out.  The fd() extension,
> ironically, is a good example of this.  People have reported bugs with
> fd() not working on platforms which don't use integers as "file handles,"
> just because they thought it was a standard function.

Whatever; all I needed was a way of accessing the descriptor so that I
could pass it to fcntl(). Someone suggested a type-conversion operator
that would allow access to the underlying FILE*, and that would work
for me too. The exact interface/ implementation details are largely
irrelevant.

And while I understand your reluctance to add extra interfaces,
consider how this looks from the other side of the fence: you are so
afraid of even *one* extra interface that you would rather your users
dredge through *all* the internal interfaces in libstdc++, *all* of
which may conceivably change without warning at the next upgrade! Of
course, I can see how this might be appealing - the responsibility for
maintaining all of those non-standard extensions is now thrust
completely onto your users' shoulders instead. However, as I said
earlier, it was the *capability* to access the descriptor that I
needed. I could have maintained that one line of code in my program
against whatever interface changes you made so long as that capability
remained intact.

I personally think that I made the correct choice in porting away from
g++, at least for now.

Sincerely,
Chris Rankin