This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: filebuf::fd()


Nathan Myers <ncm-nospam@cantrip.org> writes:

[...]

| > 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.
| > | +      int 
| > | +      fd();
| > 
| > Replace this with
| > 
| > +   #ifdef _GLIBCPP_USE_EXTENSIONS
| > +      FILE*
| > +      FILE_pointer();
| > +   #endif
| 
| I strongly object to this.  
| 
| 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.

Well, I'm not suggesting we should use FILE* to implement the
underlying stream.  However, either the stdio-based solution or
libio-based solution somehow sync with the FILE* thingy, so I think
we're better off just returning the FILE* thingy -- there is no
further commitment than there is with returning an int.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]