D
derek
I see this has come up over and over again in the past... that
programmers waste hours of confusion when using a fstream object to
open, read/write, close then attempt to open another file (or the same
file) with the same object, and wonder why operations are failing.
If standard C's open/fopen functions will open a file without caring
about previous error states of the filehandle, then C++ should do the
same with fstream:pen, or at the very least make it extremely clear
in all fstream documentation that you should call clear() before
calling open a second time.
In addition, it is quite annoying for C++ to block all I/O operations
upon the result of any error (for example, when reading from a stream,
if you get an invalid multibyte character, you have to call clear()
before you can do anything further).
What could be nice clean code results in being cluttered with numerous
calls to clear().
programmers waste hours of confusion when using a fstream object to
open, read/write, close then attempt to open another file (or the same
file) with the same object, and wonder why operations are failing.
If standard C's open/fopen functions will open a file without caring
about previous error states of the filehandle, then C++ should do the
same with fstream:pen, or at the very least make it extremely clear
in all fstream documentation that you should call clear() before
calling open a second time.
In addition, it is quite annoying for C++ to block all I/O operations
upon the result of any error (for example, when reading from a stream,
if you get an invalid multibyte character, you have to call clear()
before you can do anything further).
What could be nice clean code results in being cluttered with numerous
calls to clear().