Question about fstream operator >> and <<

[neowillis]

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.

[Bo Persson]

ne*******@gmail.com 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

[BobR]

<ne*******@gmail.comwrote 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

[Victor Bazarov]

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

[BobR]

Victor Bazarov <v.********@comAcast.netwrote in message
news:bc******************************@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. <GBack to work for me.
--
Bob R
POVrookie

[James Kanze]

On Mar 31, 9:52 pm, "Victor Bazarov" <[e-mail]:

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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]