roxtar at November 17th, 2005 09:39 — #1
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?
monjardin at November 17th, 2005 09:58 — #2
I googled this: http://www.gnu.org/software/libc/manual/html\_node/Streams-and-File-Descriptors.html
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.
roxtar at November 17th, 2005 10:02 — #3
I googled for this but couldn't find anything. Thanks
oisyn at November 17th, 2005 11:42 — #4
I should go for the iostream library if you're using C++, since you can't really derive your own FILE* or filedescriptor
eddie at November 17th, 2005 12:49 — #5
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.
roxtar at November 17th, 2005 14:37 — #6
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?
eddie at November 17th, 2005 14:56 — #7
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."
oisyn at November 17th, 2005 15:53 — #8
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
eddie at November 17th, 2005 15:58 — #9
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.
nils_pipenbrinck at November 22nd, 2005 08:26 — #10
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.
groundkeeper at December 22nd, 2005 17:00 — #11
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!
eddie at December 25th, 2005 17:09 — #12
Beautiful, with ugly syntax.