streams and FILE* interoperability

S

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

=?ISO-8859-2?Q?Milan_=C8erm=E1k?=

sb napsal(a):
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 interoperability 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.

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

P.J. Plauger

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.

Sadly, yes. The capability went in and out of the draft C++ Standard
a couple of times, but ended up out.
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 interoperability 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* ?

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

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
 
E

Evan Carew

-----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/Prlj9GScRApfYAJ92uO7YntflXiUkOWyXZNfkcHaJgQCeOola
zbBMlFdcKXyI4ozWcbS3sJg=
=L1m9
-----END PGP SIGNATURE-----
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

file streams 1
Streams 4
file streams 3
Java 8 Streams and Eratosthenes 22
Noob on memory and data streams... 4
Java with JSON file 3
"Streams" 8
Binary vs. formatted std::string reading/writing to streams 2

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top