File Streams Vs File descriptors

F373d9db2d13fdef465493773a6affab
0
roxtar 101 Nov 17, 2005 at 14:39

I have been using file streams and file descriptors (I mean *nix file descriptors) for programming for some time, but I really couldn’t pin point what is the exact difference between the two. Other than the fact that one is of type: int and the other is of type: FILE *, what are the other differences? There are facilities for reading, writing, opening, creating, seeking etc in both. Are there any advantages of using one over the other?

11 Replies

Please log in or register to post a reply.

6f0a333c785da81d479a0f58c2ccb203
0
monjardin 102 Nov 17, 2005 at 14:58

I googled this: http://www.gnu.org/software/libc/manual/html_node/Streams-and-File-Descriptors.html

Summary:
Streams are a higer level interface on top of file descriptors with richer input and output operations. File descriptors are necessary for control operations specific to a certain device. They suggest prefering streams as they are more portable and easier to use. Also, you can extract a file descriptor from a stream or create a stream with an open file descriptor.

F373d9db2d13fdef465493773a6affab
0
roxtar 101 Nov 17, 2005 at 15:02

I googled for this but couldn’t find anything. Thanks

340bf64ac6abda6e40f7e860279823cb
0
_oisyn 101 Nov 17, 2005 at 16:42

I should go for the iostream library if you’re using C++, since you can’t really derive your own FILE* or filedescriptor ;)

Cd577ee1cb56aa2ad5645b7daa0a2830
0
eddie 101 Nov 17, 2005 at 17:49

I personally prefer file streams myself, for the reasons that .oisyn mentioned. (I have a nifty class I call a ForkingStream that’ll accept input through operator<< and pipe it to 0-to-n items that derive from ostream: very handy for logging).

That said, because FILE *’s are lower level, they’re generally faster, although you lose a lot in terms of type safety, and I *believe* you can open the door to a few security issues (or is that only sprintf() and the like that I’m thinking of? Not sure0.

Anyhow, hope that helps.

F373d9db2d13fdef465493773a6affab
0
roxtar 101 Nov 17, 2005 at 19:37

@eddie

That said, because FILE *’s are lower level, they’re generally faster, although you lose a lot in terms of type safety,

I was just wondering: What is the performance hit of creating a wrapper class over a low level library/system call? Has anyone tried profilling that?

Cd577ee1cb56aa2ad5645b7daa0a2830
0
eddie 101 Nov 17, 2005 at 19:56

Well naturally, it depends how much work your wrapper is doing. One level of indirection is not going to be too muych of an issue, and with today’s hardware you should be more concerned with getting your higher level issues sorted out, as that’s where your bottlenecks will be alleviated much easier.

Donald Knuth said it best. “Premature optimization is the root of all evil.”

340bf64ac6abda6e40f7e860279823cb
0
_oisyn 101 Nov 17, 2005 at 20:53

Indeed, and the task of actually writing to disk or to another process (which is usually the case when writing to a “file”) has substantially more overhead than the extra level of indirection in your code ;)

Cd577ee1cb56aa2ad5645b7daa0a2830
0
eddie 101 Nov 17, 2005 at 20:58

That’s a very good point too. If you’re wrapping a system call to your hard-drive, you’re going to be IO bound a lot sooner then you will be CPU bound by your level of indirection.

Just don’t go wraptastically crazy. :) Make sure what you’re doing makes sense.

B91eae75cd6245bd8074bd0c3f1cc495
0
Nils_Pipenbrinck 101 Nov 22, 2005 at 13:26

btw.

If I’m not mistaken filehandles are not buffered while FILE * style acesses are (under certain circumstances).

That makes a performance difference if you do lot of small writes.

I’m into memory mapped IO these days.. it’s just so much faster and more flexible.

6cad28055d4af37574fe0d4064555e53
0
GroundKeeper 101 Dec 22, 2005 at 22:00

Another plus (atleast for me) is that STL is just that Templated which gives a first step toward generic libraries!

Sorry for the typical software engineer comment.. ;) Templates are just so beautiful! ;P

Cd577ee1cb56aa2ad5645b7daa0a2830
0
eddie 101 Dec 25, 2005 at 22:09

Beautiful, with ugly syntax. :)