13

Possible Duplicates:
Is std::ifstream significantly slower than FILE?
Which I/O library do you use in your C++ code?

I was wondering what are the pros or cons of using fstream over FILE in C++?

The one pro I think is that FILE is more efficient than fstream.

Community
  • 1
  • 1
Vineet G
  • 175
  • 1
  • 1
  • 8
  • 1
    The title of this question makes it an excellent candidate as a canonical question on the issue, especially given that there's an excellent accepted answer. I think that this question can be interpreted specifically as a technology question with a specific answer (as well as a more general question regarding a recommendation for a choice of library, which seems to be the interpretation that caused the question to be closed, given the two questions that appear listed as duplicates) - so I've voted to reopen the question. – Dan Nissenbaum Feb 06 '15 at 05:40

3 Answers3

53

One is C and one is C++. Tomato, tomato. (That expression doesn't work nearly as well when you write it out.) My guess is that you are not likely to see a performance difference.

A very C++ inclined, anti-C person will probably tell you something along the lines of fstream being able to deal with differing types with more ease. With FILE you have two options -- deal in bytes or deal in format strings. Since printf or fwrite et al. don't know what the "real" type of their arguments are this makes it easier to screw up. There's also the fact that a C++ class will have a destructor and so you get cleanup "for free" when the object goes out of scope. (Although... Do you really want something like fflush to silently happen in a destructor? Probably not.) To these sorts of arguments I would say that it's not really that much of a burden to use FILE, but hey, some people feel more strongly than I on these matters.

Eventually it will boil down to what exactly your application is trying to do, and it may be that FILE, fstream, or both can adequately suit your needs.

Pick what works, be flexible with what other people choose, understand the arguments and don't get too religious about it. That's my advice. :-)

asveikau
  • 39,039
  • 2
  • 53
  • 68
16
  • fstream is a better encapsulation and has higher level concepts.
  • fstream is exception safe.
  • fstream is also a stream and can be treated generically as a stream.

Imagine:

void read(istream& istr)

We could pass in an ifstream, a istrstream, or even cin. This is very useful for unit testing.

Jeffrey Faust
  • 547
  • 3
  • 12
5

std::fstream is typesafe, has internationalization support and is (warning: opinion) easier to use.

When a std::fstream goes out of scope it is destructed for you, regardless of whether you forgot to fstream::close() it.

octal9
  • 368
  • 1
  • 10
  • 3
    I think the "forgetting to close" argument is kind of dubious. Especially the word "forget" here implies that this will save you from having to think. That is not so. For example if you have buffered bytes a close might also have a flush, which may fail. Do you want this failure to occur in a destructor where it might be inconvenient to handle? Or would you rather it be in a predictable place alongside the rest of your I/O? Files are a good example of where automatic memory management breaks down. Similar arguments can be had about languages with GC and why not to rely on GC to close a file. – asveikau Apr 06 '11 at 17:40
  • 3
    @asveikau - I don't disagree. However, it's something that should be noted as a difference between FILE & fstream so I included it. It being a pro or con is entirely subjective. – octal9 Apr 06 '11 at 17:46