Question about fstream operator >> and <<



 DEVELOP > c-Plus-Plus > Question about fstream operator >> and <<

LINK TO THIS PAGE  


rating :  0   |  0


  Page 1 of 1

1

 
Topic: DEVELOP > c-Plus-Plus
User: ""
Date: 30 Mar 2007 08:29:30 AM
Object: Question about fstream operator >> and <<
code:
#include <iostream>
#include <fstream>
#include <string>
using namespace std;
int main()
{
fstream iofile;
string ss;
iofile.open("a.txt", fstream::in | fstream::out);
iofile.seekg(ios::beg);
iofile >> ss;
cout << ss << endl;
iofile.seekp(ios.beg);
iofile << "abcdefg" << endl;
iofile << flush;
iofile.close();
return 0;
}
Writing to the file is failed, why?
I swapped the position of the reading and writing operations, writing
is succeeded.
.

User: "BobR"

Title: Re: Question about fstream operator >> and << 31 Mar 2007 12:43:48 PM
<neowillis@gmail.com> wrote in message ...

code:

#include <iostream>
#include <fstream>
#include <string>
using namespace std;
int main(){
fstream iofile;
std::string ss;
iofile.open("a.txt", fstream::in | fstream::out);
iofile.seekg(ios::beg);
iofile >> ss;
cout << ss << endl;
iofile.seekp(ios.beg);
iofile << "abcdefg" << endl;
iofile << flush;
iofile.close();
return 0;
}

Writing to the file is failed, why?
I swapped the position of the reading and writing operations, writing
is succeeded.

How do you know it failed?
#include <iostream>
#include <fstream>
#include <string>
int main(){
using std::cout; // for NG post
using std::cerr; // for NG post
{ // scope1
std::ofstream iofile( "a.txt" ); // create file
if( not iofile.is_open() ){
cerr<<"\n fstream FAILED 0"<<std::endl;
exit( EXIT_FAILURE );
}
iofile.close();
} // scope1
std::fstream iofile( "a.txt" ); // std::ios_base::in|std::ios_base::out
if( not iofile.is_open() ){
cerr<<"\n fstream FAILED 1"<<std::endl;
exit( EXIT_FAILURE );
}
iofile << "abcdefg" <<std::endl;
if( not iofile ){
cerr<<"\n fstream FAILED 2"<<std::endl;
exit( EXIT_FAILURE );
}
iofile.seekg( 0, std::ios::beg );
string ss;
iofile >> ss;
if( not iofile.good() ){ // another way
cerr<<"\n fstream FAILED 3"<<std::endl;
exit( EXIT_FAILURE );
}
cout << ss << std::endl;
iofile.close();
return 0; // EXIT_SUCCESS
} // main() end
// output: abcdefg
Experts: Never ever tell someone they don't need to use .close() on a file
because it is going out-of-scope!! In testing the above (in my TestBench
program), I had it write "abcdefg" to another file which was in it's own
scope, inside it's own (class) method, inside a class which was locally
instantiated in it's own scope, and (file) named differently! Yeah, there
are some weird circumstances involved (MinGW(GCC3.3.1), wxWidgets 2.8.0,
many streams open, win98se), BUT, it did happen! Just be warned.
I'll report back here if I find how/why it happened (*all* my .rdbuf() tests
were commented-out, no low-level stuff active). Very strange!
--
Bob R
POVrookie
.
User: "Victor Bazarov"

Title: Re: Question about fstream operator >> and << 31 Mar 2007 02:52:30 PM
BobR wrote:

[..]
Experts: Never ever tell someone they don't need to use .close() on a
file because it is going out-of-scope!! [..]

So, should I first define a default-constructed fstream and only then
..open() it?
And in case the implementation I have is buggy, should I also work
around any potential problems by using only built-in types and
'if/else/goto' (in case there is a problem with 'switch/while/...'
or with user-defined types)? Just wondering...
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
.
User: "James Kanze"

Title: Re: Question about fstream operator >> and << 02 Apr 2007 02:06:48 AM
On Mar 31, 9:52 pm, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:

BobR wrote:

[..]
Experts: Never ever tell someone they don't need to use .close() on a
file because it is going out-of-scope!! [..]

So, should I first define a default-constructed fstream and only then
.open() it?

That's a question of style. The important thing is that
regardless of whether you pass the filename directly to the
constructor, or call open explicitly, you check whether it has
succeeded. Similarly, the important thing is that after
actually closing the file, you check whether it succeeded or
not. Which, of course, you can't do if you close the file in
the destructor.j
There are some exceptions. For example, if you're processing an
error, which means that the contents of the file are invalid
anyway, and that the file will be immediately removed, it really
doesn't matter whether the flush in the close worked or not.
And the issue is usually much less critical for input; I don't
always bother closing input files explicitly.
I might add that if you're outputting to cout, you should flush
it and check the status before returning as well.

And in case the implementation I have is buggy, should I also work
around any potential problems by using only built-in types and
'if/else/goto' (in case there is a problem with 'switch/while/...'
or with user-defined types)? Just wondering...

What on earth for? Write errors are a fact of life, and can and
must be handled. Where as you really have to assume that your
implementation is working correctly; if e.g. main memory fails
(it's happened to me), there's not much a program can do about
it. (And of course, unlike write errors, it's pretty rare.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
.

User: "BobR"

Title: Re: Question about fstream operator >> and << 01 Apr 2007 02:07:30 PM
Victor Bazarov <v.Abazarov@comAcast.net> wrote in message
news:bcydnTbPI9FsJpPbnZ2dnUVZ_sSmnZ2d@comcast.com...

BobR wrote:

[..]
Experts: Never ever tell someone they don't need to use .close() on a
file because it is going out-of-scope!! [..]


So, should I first define a default-constructed fstream and only then
.open() it?
And in case the implementation I have is buggy, should I also work
around any potential problems by using only built-in types and
'if/else/goto' (in case there is a problem with 'switch/while/...'
or with user-defined types)? Just wondering...

No, no and no. <G>
I have not investigated yet. But, I did put file.close() [which puts the
stream in a fail-state] on the 'distant' file and it didn't write to it. I
think it's something in the newer (2.8.0) wxWidgets that's messing with the
stream(s) states. It might be something I did or didn't enable when building
the wx library.
Of course we can't discuss wxWidgets here, but, a file stream created in one
scope should not mess with a file stream created in another scope (two
different file names). My TestBench program is cluttered (again) with
hundreds of little test-snippets, so maybe while 'housecleaning' I'll spot
where things got crossed (<crosses fingers>). I may just go back to my older
wxWidgets (since the executable size doubled just by linking to the newer
version), and test the file-cross thing again.
Both files were opened using 'fstream' ( no i or o), and are the only two
opened that way in the whole project ( all the rest use ifstream or
ofstream).
If you (or anyone) have something specific to look for, I'd appreciate a
response. Thanks.
Thanks for listening to my idiotic rants. <G> Back to work for me.
--
Bob R
POVrookie
.



User: "Bo Persson"

Title: Re: Question about fstream operator >> and << 31 Mar 2007 05:14:55 AM
wrote:
:: code:
::
:: #include <iostream>
:: #include <fstream>
:: #include <string>
::
:: using namespace std;
::
:: int main()
:: {
:: fstream iofile;
:: string ss;
::
:: iofile.open("a.txt", fstream::in | fstream::out);
::
:: iofile.seekg(ios::beg);
:: iofile >> ss;
:: cout << ss << endl;
::
:: iofile.seekp(ios.beg);
:: iofile << "abcdefg" << endl;
:: iofile << flush;
::
:: iofile.close();
::
:: return 0;
:: }
::
:: Writing to the file is failed, why?
:: I swapped the position of the reading and writing operations, writing
:: is succeeded.
How much text do you have in the file to start with? If your input reaches
end-of-file, that condition will stick until you do an iofile.clear().
Bo Persson
.


  Page 1 of 1

1

 


Related Articles
 

NEWER

pg.1232     pg.940     pg.716     pg.544     pg.412     pg.311     pg.234     pg.175     pg.130     pg.96     pg.70     pg.50     pg.35     pg.24     pg.16     pg.10     pg.6     pg.3     pg.1

OLDER