streams and FILE* interoperability

[sb]

I think streams are nice, but what do you do when you have to write to
or, even worse, read from a FILE*, for example a UNIX stream?

C++ streams can not be created from FILE*'s or have them attached.

Today, a C++ programmer has to decide beforehand whether he wants to
use C or C++ I/O. Suppose you choose C++ streams and write all of the
"operator>> " code for your objects. If you later decide to read the
same objects from a UNIX pipe, you'll have to rewrite and re-debug
much of that code.

Since C++ was aiming for seamless interoperabilit y with C, wouldn't it
have been easier to make its file stream a shallow wrapper around
FILE*? It already has the necessary buffering functionality. Or at
least specialize the character streams to be such bufferless wrappers
around FILE* ?

On a more positive note, I haven't used them yet, but it looks like
STLport provides such shallow stream wrappers as an option.

[Milan Èermák]

Re: streams and FILE* interoperabilit y

sb napsal(a):[color=blue]
> I think streams are nice, but what do you do when you have to write to
> or, even worse, read from a FILE*, for example a UNIX stream?
>
> C++ streams can not be created from FILE*'s or have them attached.
>
> Today, a C++ programmer has to decide beforehand whether he wants to
> use C or C++ I/O. Suppose you choose C++ streams and write all of the
> "operator>> " code for your objects. If you later decide to read the
> same objects from a UNIX pipe, you'll have to rewrite and re-debug
> much of that code.
>
> Since C++ was aiming for seamless interoperabilit y with C, wouldn't it
> have been easier to make its file stream a shallow wrapper around
> FILE*? It already has the necessary buffering functionality. Or at
> least specialize the character streams to be such bufferless wrappers
> around FILE* ?
>
> On a more positive note, I haven't used them yet, but it looks like
> STLport provides such shallow stream wrappers as an option.[/color]

For the mentioned example, UNIX pipes should not be problem. Using one
on command line redirects standard output of the first and standard
output of the second application. So if your program will read cin and
write to cout it should deal with pipes quite well.

Milan Cermak

PS: Somewhere down there in stream implementation must be instance
variable holding file descriptor.

[P.J. Plauger]

Re: streams and FILE* interoperabilit y

"sb" <spam_bait101@y ahoo.com> wrote in message
news:221dd125.0 402161159.3c221 bf3@posting.goo gle.com...
[color=blue]
> I think streams are nice, but what do you do when you have to write to
> or, even worse, read from a FILE*, for example a UNIX stream?
>
> C++ streams can not be created from FILE*'s or have them attached.[/color]

Sadly, yes. The capability went in and out of the draft C++ Standard
a couple of times, but ended up out.
[color=blue]
> Today, a C++ programmer has to decide beforehand whether he wants to
> use C or C++ I/O. Suppose you choose C++ streams and write all of the
> "operator>> " code for your objects. If you later decide to read the
> same objects from a UNIX pipe, you'll have to rewrite and re-debug
> much of that code.
>
> Since C++ was aiming for seamless interoperabilit y with C, wouldn't it
> have been easier to make its file stream a shallow wrapper around
> FILE*? It already has the necessary buffering functionality. Or at
> least specialize the character streams to be such bufferless wrappers
> around FILE* ?[/color]

C++ was aiming in a number of directions at once. Some of us did
indeed want seamless interoperabilit y with C. Others wanted to
bury C and the Standard C library, once and for all. We achieved
neither goal with Standard C++.
[color=blue]
> On a more positive note, I haven't used them yet, but it looks like
> STLport provides such shallow stream wrappers as an option.[/color]

The Dinkum C++ library retains the ability to construct a basic_filebuf
from a FILE *. Moreover, we provide efficient synchronization between
operations on the basic_filebuf and FILE objects for free. (You don't
have to turn on sync_with_stdio to get synchronization and you don't
have to turn it off to get good performance.) This capability is
a conforming extension.

We also provide the popular nonconforming extensions (which can be
disabled, of course), including attach, stdiofile, fd, and
constructors that take a file descriptor and an fopen-style mode.
All this stuff obviates the need for shallow stream wrappers.

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com

[Evan Carew]

Re: streams and FILE* interoperabilit y

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Admitidly, I use the g++ toolchain, but why can't you do something like
the following?

#include <stdiostream. h>

int main(){
FILE *fp;
fp = fopen("testing. txt", "w+");
ostdiostream myfs(fp);
myfs << "this is a test" << endl;
return 0;
}

Or, in a more standard fashion, the following:

#include <fstream.h>
#include <stdio.h>

int main(){
FILE *fp;
fp = fopen("testing. txt", "w+");
ofstream myfs(fileno(fp) );
myfs << "this is a test" << endl;
return 0;
}

Is it because the first case is found only in the gcc tool chain & the
second case isn't strictly speaking all in the C++ library?

Evan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAMUx9oo/Prlj9GScRApfYAJ 92uO7YntflXiUkO WyXZNfkcHaJgQCe Oola
zbBMlFdcKXyI4oz WcbS3sJg=
=L1m9
-----END PGP SIGNATURE-----