Re: filebuf::fd()

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

On Mon, Dec 03, 2001 at 07:24:30AM +0000, Nathan Myers wrote:
> > |     1)  for is_open, make it clear that we're comparing pointers.
> 
> I would suggest comparing to (FILE*)0 if you think it's important to 
> clarify what's going on.  NULL is a C-ism and, in C++, is meaningless
> to the compiler.

On the contrary, NULL is defined to the magical __null, which g++ knows
can only be a pointer value.  It's one of the builtin identifier nodes.

Comparing to 0 doesn't look intuitive to beginners.


> I agree that this is an important extension.  Ideally we'd like for 
> users to get a warning if they call it when --pedantic is turned on.

I have some ideas there, too, once the rest of this is settled.


> > I discussed the issue with Theo two weeks ago.  I think returning a
> > FILE* would be self-contained in terms of semantics.  That is, isntead
> > of retuning an int (the file descriptor), have a member function --
> > say FILE_pointer() -- return a FILE*.  That scheme is extensible to
> > libio.

That was my proposal back in September.  Nobody liked it.  :-)

> There is no standard requirement nor practical reason for a filebuf 
> to have a FILE underneath, but it necessarily uses a file descriptor
> in a POSIX environment.  I don't think we should be documenting an 
> interface that commits us to an implementation technique we would be 
> better off freeing ourselves from.

Here's what really burns me about returning a file descriptor:  the library
never uses one.  Anywhere.

On the other hand, we've cleverly layered all the operations through
a __basic_file interface, with currently two choices of underlying
implementation.  (One of which won't compile, that's beside the point.)
I feel we should expose that layer instead.

If a third I/O choice comes along -- some PDA, for example, with one of
those tiny PCMCIA drives -- which doesn't use type 'int' to represent file
handles, /then/ we'll look like idiots for making too many assumptions.
The __basic_file probably won't be FILE* (like in stdio) nor whatever funky
type gets used in libio, but it /will/ make sense to the programmers using
that platform, and they'll know what to do with whatever type we pass back.

Is it really too hard to write

    int fd = fileno( (FILE*) a_filebuf.get_underlying_object() );

in the stdio case, instead of

    int fd = a_filebuf.fd();

?


I didn't really want to have this debate all over again... ah screw it.
Somebody just make a call so I can check the code in, write it up in the
docs, and go back to playing with allocators.  :-)


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams