fstream::open

[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::open, 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().

[Julián Albo]

de***@idirect.com wrote:

same with fstream::open, or at the very least make it extremely clear
in all fstream documentation that you should call clear() before
calling open a second time.

Sorry, but I don't think that the standard definition of a language must
specify how books and papers about the language must be written. People can
choose what books to read according to his previous knowledge a experience
in programming in general and the language in particular.

--
Salu2

[derek]

I noticed how you avoided the real issue ;)

[Dietmar Kuehl]

de***@idirect.com wrote:

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.

You might want to check the resolution to LWG issue 22:
<http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22>.
This issue was discussed several times at varying but exhaustive
length. Personally, I consider it a non-issue as in modern C++ it
is pretty rare to reuse such objects anyway so why bother with this
case?
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence

[derek]

Say you had a program that was an implementation of something like the
unix program "split".

I'd assume the most efficient way to write it in C++ would be to use
the same static ofstream object to open each new output file.

Speaking of which, what is the most effiecient C++ method to generate a
dynamic filename for such a purpose as mentioned above?

[Dietmar Kuehl]

de***@idirect.com wrote:

I'd assume the most efficient way to write it in C++ would be to use
the same static ofstream object to open each new output file.
For unformatted reading as split(1) does? Hardly... I would expect
better performance by using 'std::filebuf' directly, although not
much better: Probably most of the time is spent waiting for I/O
anyway. The time necessary to construct an 'ofstream' for each
fragment is probably not distinctly measurable in either situation.
Speaking of which, what is the most effiecient C++ method to generate a
dynamic filename for such a purpose as mentioned above?

You mean what is the most efficient method to create a sequence
of strings containing increasing numbers? Probably maintaining
an array of digits.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence