11 replies to this topic

[roxtar]

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]

I googled this: http://www.gnu.org/s...escriptors.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.

[roxtar]

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

[.oisyn]

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

[eddie]

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]

eddie said:

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]

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]

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]

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]

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.

[GroundKeeper]

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

[eddie]

Beautiful, with ugly syntax. :)