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: The patch for PR libstdc++/14097.



Richard.Kreckel@framatome-anp.com said:
>>                           The fact that we expose any of this concrete
>> detail as an extension boggles the mind...

> For the record, I have to disagree.  And it seems I am not alone.
> Quoting from <http://gcc.gnu.org/ml/libstdc++/2001-09/msg00057.html>:
> "On UNIX-like systems, there should be a way to get a file descriptor
> from an stream, in the cases where there really is an underlying
> descriptor." 

It has been at least 2 or 3 years that I'm stuck because of this (I 
want to memory map part of files sometimes).
This is since the dropping of the fd extensions on iostreams (mostly
because there was a plan to do iostreams over libio which never happened 
anyway...).

Exposing internal implementation is bad as long as people make 
commitment on it (support, etc)... If there is no way to provide a 
better solution, then allow some of them (as little and as general as possible and with 
all red flags up saying that this is an unsupported extension, that 
may disappear soon and that can lead to problems with may or may not 
be solved by the libstdc++-v3 team if reported). Actually, my 
preferred solution would be to put a friend function (eg 
os_file_descriptor) in basic_filebuf and put such a function as an 
extension.

Is it bad ?    Yes.
Is it useful ? Yes.

Can it be misused ? Yes, so what...
If people restrict themselves just to to enquiries on the stream 
(eg isatty) there should be no problems. If they do not intermix C 
and C++ ios also, so be it and document it this way.

Is there a better way to do it ?
Not as such, but providing all the posix functionality on FILE's is 
an ambitious project that can be dealt only by the C++ committee and 
requires a huge amount of work.

It's just a temporary hack and nothing is wrong as long as it is 
documented as such and that no commitment is made at supporting the 
hack in the future nor at correcting strange behaviours arising from 
it.


--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------



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