What does fstream::getline() return after setting fail bit?

Discussion in 'C++' started by Disc Magnet, Mar 4, 2010.

  1. Disc Magnet

    Disc Magnet Guest

    I wrote this code:

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

    using namespace std;

    int main()
    {
    fstream f("foo.txt");
    char s[10];

    while (f.getline(s, 10)) {
    cout << "[" << s << "]" << endl;
    cout << "eof: " << f.eof() << "; fail: " << f.fail() << "; "
    << "bad: " << f.bad() << "; good: " << f.good() << endl;
    cout << endl;
    }
    cout << "Outside loop" << endl << endl;
    cout << "[" << s << "]" << endl;
    cout << "eof: " << f.eof() << "; fail: " << f.fail() << "; "
    << "bad: " << f.bad() << "; good: " << f.good() << endl;
    cout << endl;
    return 0;
    }

    When I run this code, I get the following output:

    [A2345]
    eof: 0; fail: 0; bad: 0; good: 1

    [B23456789]
    eof: 0; fail: 0; bad: 0; good: 1

    Outside loop

    [C23456789]
    eof: 0; fail: 1; bad: 0; good: 0

    It seems fstream::getline() sets the fail flag to true when the line
    encountered is longer than the limit specified. But why does the if ()
    ( condition evaluate to false?

    I couldn't find any information pertaining to the return value of
    getline() here: http://stdcxx.apache.org/doc/stdlibref/basic-istream.html#idx173
    Is this the right documentation or do I need to look at some other
    documentation?
    Disc Magnet, Mar 4, 2010
    #1
    1. Advertising

  2. Disc Magnet

    John H. Guest

    On Mar 4, 2:17 pm, Disc Magnet <> wrote:
    > It seems fstream::getline() sets the fail flag to true when the line
    > encountered is longer than the limit specified. But why does the if ()
    > ( condition evaluate to false?


    As you have seen, an fstream is designed to be able to evaluate like a
    boolean value, where true means healthy and false means problem.
    The mechanism you see is that getline returns a reference to the
    object it was called on, and then that object gets converted into a
    void*. This void* is null on error and non-null when things go ok.

    > Is this the right documentation or do I need to look at some other
    > documentation?


    You might take a peek at
    http://www.cplusplus.com/reference/iostream/fstream/
    John H., Mar 4, 2010
    #2
    1. Advertising

  3. Disc Magnet

    Ben Cottrell Guest

    John H. wrote:
    > On Mar 4, 2:17 pm, Disc Magnet <> wrote:
    >
    >>It seems fstream::getline() sets the fail flag to true when the line
    >>encountered is longer than the limit specified. But why does the if ()
    >>( condition evaluate to false?

    >
    >
    > As you have seen, an fstream is designed to be able to evaluate like a
    > boolean value, where true means healthy and false means problem.
    > The mechanism you see is that getline returns a reference to the
    > object it was called on, and then that object gets converted into a
    > void*. This void* is null on error and non-null when things go ok.


    I've always felt that this is a bit of an odd thing for the stream
    classes to do, I would think it more sensible to have operator bool
    defined instead. is there some subtle reason why operator void* is
    used here?
    Ben Cottrell, Mar 4, 2010
    #3
  4. Disc Magnet

    James Kanze Guest

    On 5 Mar, 11:48, Pete Becker <> wrote:
    > Ben Cottrell wrote:
    > > John H. wrote:
    > >> On Mar 4, 2:17 pm, Disc Magnet <> wrote:


    > >>> It seems fstream::getline() sets the fail flag to true
    > >>> when the line encountered is longer than the limit
    > >>> specified. But why does the if () ( condition evaluate to
    > >>> false?


    > >> As you have seen, an fstream is designed to be able to
    > >> evaluate like a boolean value, where true means healthy and
    > >> false means problem. The mechanism you see is that getline
    > >> returns a reference to the object it was called on, and
    > >> then that object gets converted into a void*. This void*
    > >> is null on error and non-null when things go ok.


    > > I've always felt that this is a bit of an odd thing for the
    > > stream classes to do, I would think it more sensible to have
    > > operator bool defined instead. is there some subtle reason
    > > why operator void* is used here?


    > There was an irrational fear that conversion to bool would
    > result in coding errors when a stream object was used in a
    > numeric context. That was followed by an irrational fear that
    > converting to void* would result in coding errors if someone
    > tried to delete a stream object.


    I'm not sure that the word "irrational" is appropriate in this
    context. Historically, bool wasn't available, and the
    conversion to int was felt to have some dangers (but of course,
    what doesn't?). If the committee had been willing to change it,
    a convertion to a pointer to member would seem the safest,
    assuming it considered the risks important, and a conversion to
    bool the most logical, assuming it didn't consider the risks
    that important. Globally, at the committee level, I suspect it
    was more a question of not wanting to change something that had
    been that way for ages. (But of course, they changed a lot of
    other things, and broke a significant amount of code, sometimes
    for no benefit whatsoever.)

    --
    James Kanze
    James Kanze, Mar 5, 2010
    #4
    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. Kai Wu
    Replies:
    6
    Views:
    759
    Kai Wu
    Oct 10, 2004
  3. Peter Gordon
    Replies:
    2
    Views:
    4,548
    Peter Gordon
    Mar 15, 2005
  4. shyam
    Replies:
    3
    Views:
    631
    shyam
    Jan 15, 2007
  5. rory
    Replies:
    15
    Views:
    3,777
    James Kanze
    Jan 25, 2008
Loading...

Share This Page