ajrobb@ecr.mu.oz.au (Andrew_J ROBBIE) writes:

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

This is the role of Posix, not the C++ standards.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ 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              ]

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              ]

dietmar.kuehl@claas-solutions.de writes:

|>  In article <3561480D.18DAE41D@acco.net>,
|>    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.

On the other hand, it shouldn't be that difficult to cobble up a
FILEstreambuf, which reads and writes from a FILE*.  Total
synchronization for output would be trivial, but I'm not sure it is even
possible for input -- you'd need some sort of command to tell the
FILEstreambuf to synchronize before starting FILE* input.

The basic principle should be quite close to that of my filtering
streambuf's, with the final sink/source a FILE* rather than another
streambuf.  The main differences (all of which pose significant
problems):

1. My filtering streambuf's make no effort to be bidirectional -- there
are two distinct versions, one for input, and one for output.

2. My filtering streambuf's don't worry about synchronization; they
assume that no one else is using the final sink/source while they're
active.

3. My filtering streambuf's don't support seeking.

In many cases, I suspect that all of these restrictions should be
acceptable, and a simple modification of the filtering streambuf's
should do the trick.  A general solution, however, is far from trivial;
I'm not even convinced that it can be done for input.  (I think you need
a special function to tell the FILEstreambuf that the next input might
be from the FILE*, so that it can ungetc any character in its buffer.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung


[ 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              ]

In article <6k0nmi$sfb$1@mulga.cs.mu.OZ.AU>,
Andrew_J ROBBIE <ajrobb@ecr.mu.oz.au> wrote:
>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?

You could simply require that any buffers be flushed when switching between
C- and C++-style I/O with a particular stream.

Considering that C++ includes 'export "C"' to make it easy to link between
C and C++, and POD classes that are expected to be compatible with C
(although I don't think this is required), it seems like providing a way to
interface between C++ and C I/O would make sense.  One possibility is a
conversion operator, and another is a way to make an iostream that uses a
FILE* as its source or destination and a way to make a FILE* that uses an
iostream as its source or destination.  Just as POSIX provides fdopen()
fileno(), C++ could provide iosopen() and a FILEstream class.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.


[ 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              ]

Andrew_J ROBBIE <ajrobb@ecr.mu.oz.au> wrote:
: 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?

The C/C++ language standard is produced by ANSI/ISO C/C++ language
standartization committies. Unix/Posix extentions are created
by other people for totally different purposes. It is not
a job of a language committee to provide a Posix API as well.

Now that C++ standard is really close, I hope Posix people will
come together and define Posix extentions and possibly Posix
C++ API. The former would include an ability to extract
a file descriptor from an fstream, and the later would
include a good C++ interface for common Posix C functions
and structures.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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              ]

I have C I/O-functions operating on FILE*stream. Is it possible to get a
FILE pointer
from any iostream (e.g. istrstream)?

If so, it would save me a lot of porting work!

Thanks in advance

Marc Dzaebel, R.O.S.E. Informatik, Tel:07321/9593-14



[ 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              ]

Hi,
In article <3561480D.18DAE41D@acco.net>,
  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.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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              ]

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?

Regards,
Andrew



[ 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              ]

J. Kanze <kanze@gabi-soft.fr> wrote in article
<m3emxmflxc.fsf@gabi-soft.fr>...
> dietmar.kuehl@claas-solutions.de writes:
>
> |>  In article <3561480D.18DAE41D@acco.net>,
> |>    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.
>
> On the other hand, it shouldn't be that difficult to cobble up a
> FILEstreambuf, which reads and writes from a FILE*.  Total
> synchronization for output would be trivial, but I'm not sure it is even
> possible for input -- you'd need some sort of command to tell the
> FILEstreambuf to synchronize before starting FILE* input.
>
> The basic principle should be quite close to that of my filtering
> streambuf's, with the final sink/source a FILE* rather than another
> streambuf.  The main differences (all of which pose significant
> problems):
>
> 1. My filtering streambuf's make no effort to be bidirectional -- there
> are two distinct versions, one for input, and one for output.
>
> 2. My filtering streambuf's don't worry about synchronization; they
> assume that no one else is using the final sink/source while they're
> active.
>
> 3. My filtering streambuf's don't support seeking.
>
> In many cases, I suspect that all of these restrictions should be
> acceptable, and a simple modification of the filtering streambuf's
> should do the trick.  A general solution, however, is far from trivial;
> I'm not even convinced that it can be done for input.  (I think you need
> a special function to tell the FILEstreambuf that the next input might
> be from the FILE*, so that it can ungetc any character in its buffer.)

Take a look at <fstream> in VC++ V4.2/V5.0. It supports, as a conforming
extension, the constructor:

basic_filebuf(FILE * = 0);

In other words, you can construct a file buffer that works with an existing
FILE object from the C library. Even better, the member functions in
basic_streambuf (see <streambuf>) are jiggered to perform I/O directly to
and from the C buffer. The net effect is that you get synchronization for
free and a transfer rate that approaches that of a buffered copy loop in C
(which in turn approaches that of a buffered copy loop in assembly
language). You can even do seeks, either from C or C++. And you can
do both reads and writes to the same file buffer, provided you honor the
requirement that a seek must intervene between read and write, or
between write and read.

Not all C librarys support this kind of close buffer sharing, but many do.
The alternative, for tight synchrony between C and C++, is
character-at-a-time
transfers, which can be up to 50 times slower. Thus, I can usually wheedle
customers into changing their getc/putc machinery to meet the requirements
of the streambuf primitives.

FWIW, this signature was in the draft C++ Standard for a spell, but it
was removed.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ 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              ]

In article <01bd8828$4cf2eca0$8a1ec2d0@porky>,
  "P.J. Plauger" <pjp@dinkumware.com> wrote:
>
> J. Kanze <kanze@gabi-soft.fr> wrote in article
> <m3emxmflxc.fsf@gabi-soft.fr>...
> > dietmar.kuehl@claas-solutions.de writes:
> >
> > |>  In article <3561480D.18DAE41D@acco.net>,
> > |>    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.
> >
> > On the other hand, it shouldn't be that difficult to cobble up a
> > FILEstreambuf, which reads and writes from a FILE*.  Total
> > synchronization for output would be trivial, but I'm not sure it is even
> > possible for input -- you'd need some sort of command to tell the
> > FILEstreambuf to synchronize before starting FILE* input.

    [...]

> Take a look at <fstream> in VC++ V4.2/V5.0. It supports, as a conforming
> extension, the constructor:
>
> basic_filebuf(FILE * = 0);
>
> In other words, you can construct a file buffer that works with an existing
> FILE object from the C library. Even better, the member functions in
> basic_streambuf (see <streambuf>) are jiggered to perform I/O directly to
> and from the C buffer. The net effect is that you get synchronization for
> free and a transfer rate that approaches that of a buffered copy loop in C
> (which in turn approaches that of a buffered copy loop in assembly
> language). You can even do seeks, either from C or C++. And you can
> do both reads and writes to the same file buffer, provided you honor the
> requirement that a seek must intervene between read and write, or
> between write and read.

This is, of course, the ideal solution.  It is only really available,
however, if you can control both the C and C++ library implementation --
which is not the case of most of us.

If you're not worried about portability, and willing to risk incompatiblity
with future releases of your compiler, you might be able to hack something
similar by looking at the expansion of the macros in stdio.h.  It's not
something I'd recommend.  (Lobbying your compiler vendor to provide this
extension, however, sounds like a good idea though.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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              ]