Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > fstream::open

Reply
Thread Tools

fstream::open

 
 
derek@idirect.com
Guest
Posts: n/a
 
      12-08-2005
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().

 
Reply With Quote
 
 
 
 
=?ISO-8859-15?Q?Juli=E1n?= Albo
Guest
Posts: n/a
 
      12-08-2005
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> 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.


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
 
Reply With Quote
 
 
 
 
derek@idirect.com
Guest
Posts: n/a
 
      12-08-2005
I noticed how you avoided the real issue

 
Reply With Quote
 
Dietmar Kuehl
Guest
Posts: n/a
 
      12-08-2005
(E-Mail Removed) 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?
--
<(E-Mail Removed)> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
 
Reply With Quote
 
derek@idirect.com
Guest
Posts: n/a
 
      12-08-2005
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?

 
Reply With Quote
 
Dietmar Kuehl
Guest
Posts: n/a
 
      12-09-2005
(E-Mail Removed) 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.
--
<(E-Mail Removed)> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments