Re: Accessing the UNIX file descriptor inside an fstream

[Phil Edwards <pedwards at disaster dot jaj dot com>]

On Mon, Sep 17, 2001 at 10:41:18PM -0700, Chris Rankin wrote:
> > 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!"...

And land mines.  Don't forget the land mines.  :-)

Yeah, the rdbuf() function being hidden in that way is most annoying,
but that's just the way overriding goes.  Having to mention the "<char>"
part is also annoying, since that's duplicating information everywhere.
You could probably use one of the class' typedefs for basic_ios<char>
instead, but it's Yet Another Nonportable Construct.


> > 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?

(As an aside, you might be amazed at just how much of the standard is
listed as implementation-defined or undefined.)

Actually, I misspoke.  The 3.x implementation should be safe; I just
re-examined the code.  I think I remember now some discussion about this
issue a long while back, and steps being taken to make it safe.  IIRC, it's
not guaranteed by the standard, but rather a "quality of implementation"
issue, meaning that it's legal for an implementator to make it suck,
but it'd be nice if we don't.

What you mostly have to watch is making sure that the old filebuf returned
from rdbuf() is properly closed, etc.


> 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.

Maybe I'm thinking of different functions as "internal" than you are.
Certainly the protected and private functions that are meant to be overriden
or augmented by derived classes must be documented.  Nearly all of the
extra functionality for derived classes is meant to be done in terms of
overriding protected functions.

The /really/ internal functions (the _M_* ones), on the other hand... enh,
that's debatable.  In fact, we have this debate a lot on the libstdc++ list.
:-)  There's nothing stopping a derived class from using them, but they
change much more often.


Phil

-- 
Would I had phrases that are not known, utterances that are strange, in
new language that has not been used, free from repetition, not an utterance
which has grown stale, which men of old have spoken.
                                     - anonymous Egyptian scribe, c.1700 BC