C vs C++ file handling

Question

I have been working in C and C++ and when it comes to file handling I get confused. Let me state the things I know.

In C, we use functions:

• fopen, fclose, fwrite, fread, ftell, fseek, fprintf, fscanf, feof, fileno, fgets, fputs, fgetc, fputc.
• FILE *fp for file pointer.
• Modes like r, w, a

I know when to use these functions (Hope I didn't miss anything important).

In C++, we use functions / operators:

• fstream f
• f.open, f.close, f>>, f<<, f.seekg, f.seekp, f.tellg, f.tellp, f.read, f.write, f.eof.
• Modes like ios::in, ios::out, ios::bin , etc...

So is it possible (recommended) to use C compatible file operations in C++? Which is more widely used and why? Is there anything other than these that I should be aware of?

Answer 1

Sometimes there's existing code expecting one or the other that you need to interact with, which can affect your choice, but in general the C++ versions wouldn't have been introduced if there weren't issues with the C versions that they could fix. Improvements include:

• RAII semantics, which means e.g. fstreams close the files they manage when they leave scope

• modal ability to throw exceptions when errors occur, which can make for cleaner code focused on the typical/successful processing (see http://en.cppreference.com/w/cpp/io/basic_ios/exceptions for API function and example)

• type safety, such that how input and output is performed is implicitly selected using the variable type involved

  • C-style I/O has potential for crashes: e.g. int my_int = 32; printf("%s", my_int);, where %s tells printf to expect a pointer to an ASCIIZ character buffer but my_int appears instead; firstly, the argument passing convention may mean ints are passed differently to const char*s, secondly sizeof int may not equal sizeof const char*, and finally, even if printf extracts 32 as a const char* at best it will just print random garbage from memory address 32 onwards until it coincidentally hits a NUL character - far more likely the process will lack permissions to read some of that memory and the program will crash. Modern C compilers can sometimes validate the format string against the provided arguments, reducing this risk.

• extensibility for user-defined types (i.e. you can teach streams how to handle your own classes)

• support for dynamically sizing receiving strings based on the actual input, whereas the C functions tend to need hard-coded maximum buffer sizes and loops in user code to assemble arbitrary sized input

Streams are also sometimes criticised for:

• verbosity of formatting, particularly "io manipulators" setting width, precision, base, padding, compared to the printf-style format strings

• a sometimes confusing mix of manipulators that persist their settings across multiple I/O operations and others that are reset after each operation

• lack of convenience class for RAII pushing/saving and later popping/restoring the manipulator state

• being slow, as Ben Voigt comments and documents here