From 5228291961596349856
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,975e78bef1b26ee8
X-Google-Attributes: gidf78e5,public
From: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Subject: Re: iostream -> FILE*
Date: 1998/05/22
Message-ID: <3565707E.376F65FE@physik.tu-muenchen.de>#1/1
X-Deja-AN: 356336900
Content-Transfer-Encoding: 7bit
Approved: stephen.clamage@sun.com (comp.std.c++)
References: <3561480D.18DAE41D@acco.net> <6jv28m$u37$1@nnrp1.dejanews.com> <6k0nmi$sfb$1@mulga.cs.mu.OZ.AU>
Mime-Version: 1.0
Originator: clamage@taumet
X-Nntp-Posting-Host: coulomb.t30.physik.tu-muenchen.de
X-UID: 0000000001
X-Status: $$$T
Content-Type: text/plain; charset=us-ascii
Organization: [posted via] Leibniz-Rechenzentrum, Muenchen (Germany)
Newsgroups: comp.std.c++


Andrew_J ROBBIE wrote:
> 
> dietmar.kuehl@claas-solutions.de wrote:
> :   Marc Dzaebel <marc@acco.net> wrote:
> : > I have C I/O-functions operating on FILE*stream. Is it possible to get a
> : > FILE pointer
> : > from any iostream (e.g. istrstream)?
> 
> : No. It is not even possible to get a 'FILE*' from an '[io]fstream'.
> : However,
> : there are some libraries (eg. the current libg++) where you can use an
> : arbitrary 'streambuf*' when a 'FILE*' is required (at least, libg++ had a
> : feature like this). But, of course, this is not a portable feature.
> 
> This has come up before (and it keeps coming up in my code) - you have a
> piece of standard, vanilla, ANSI/ISO C code, which uses FILE* to do I/O,
> and you want to interface it to a piece of C++.
> 
> Now, it seems to me that a conversion from FILE* to fstream (and vice
> versa) would be really useful. No doubt there are problems with buffering,
> etc, but are they that bad?
> 
> The other thing which crops up is the problem of finding the file
> descriptor from a C++ stream object. At this stage, people will start
> saying "but DOS doesn't have file descriptors, that wouldn't be
> portable, go away". And then they say totally unrealistic things
> like "don't use fstat to calculate file size, count the number of
> bytes in it".
> 
> But huge amounts of code are written for un*x systems - systems for
> which C++ programmers need a standard way of doing things. Couldn't
> there be stream specialisations for each API? And couldn't the
> standard provide an 'example' specialisation for posix-type systems?
> Sure, compilers can provide extensions, but can't compiler vendors
> be guided in the same direction?

I think it's quite the opposite: The POSIX standard should define
C++ interfaces as well as C interfaces. For example, POSIX could
say that every POSIX compliant C++ implementation has the member
fstream::stat. It could also mandate that you have functions to
get a streambuf from a FILE* and a FILE* from a streambuf. It could
also mandate a member filebuf::fd().
The C++ standard must not get specific for a special environment.
However POSIX *is* a standard for a given environment. IMHO the
right and only right place to say anything about POSIX systems
is the POSIX standard.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]