Question about fstream operator >> and <<

Discussion in 'C++' started by neowillis@gmail.com, Mar 30, 2007.

  1. Guest

    code:

    #include <iostream>
    #include <fstream>
    #include <string>

    using namespace std;

    int main()
    {
    fstream iofile;
    string ss;

    iofile.open("a.txt", fstream::in | fstream::eek:ut);

    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.
     
    , Mar 30, 2007
    #1
    1. Advertising

  2. Bo Persson Guest

    wrote:
    :: code:
    ::
    :: #include <iostream>
    :: #include <fstream>
    :: #include <string>
    ::
    :: using namespace std;
    ::
    :: int main()
    :: {
    :: fstream iofile;
    :: string ss;
    ::
    :: iofile.open("a.txt", fstream::in | fstream::eek:ut);
    ::
    :: 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
     
    Bo Persson, Mar 31, 2007
    #2
    1. Advertising

  3. BobR Guest

    <> 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::eek:ut);
    > 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::eek:fstream 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::eek:ut
    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
     
    BobR, Mar 31, 2007
    #3
  4. 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
     
    Victor Bazarov, Mar 31, 2007
    #4
  5. BobR Guest

    Victor Bazarov <> wrote in message
    news:...
    > 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
     
    BobR, Apr 1, 2007
    #5
  6. James Kanze Guest

    On Mar 31, 9:52 pm, "Victor Bazarov" <> 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:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Apr 2, 2007
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Armando
    Replies:
    6
    Views:
    747
    Armando
    Jan 29, 2004
  2. David Briggs

    Problem with fstream and operator>>

    David Briggs, May 23, 2004, in forum: C++
    Replies:
    6
    Views:
    3,752
    John Harrison
    May 26, 2004
  3. Guest
    Replies:
    1
    Views:
    806
    Catalin Pitis
    Oct 21, 2004
  4. Replies:
    6
    Views:
    339
    Martin York
    Jun 21, 2008
  5. Replies:
    8
    Views:
    395
Loading...

Share This Page