istringstream::str and clear

Discussion in 'C++' started by Marc, Apr 16, 2011.

  1. Marc

    Marc Guest

    Hello,

    I noticed today that istringstream::str, which changes the underlying
    string, does not clear the error state. In particular, if you read a
    string to the end then change the string and try to read the new one,
    eofbit is still set so it fails. In a similar situation, ifstream::eek:pen
    calls clear when you open a new file. Is there a particular reason for
    this inconsistency?

    int n;
    istringstream i("1");
    i >> n;
    i.str("2");
    i >> n; // fails because we still have i.eof()
     
    Marc, Apr 16, 2011
    #1
    1. Advertising

  2. Marc

    Paul Guest

    "Marc" <> wrote in message
    news:ioc6ln$8f1$...
    > Hello,
    >
    > I noticed today that istringstream::str, which changes the underlying
    > string, does not clear the error state. In particular, if you read a
    > string to the end then change the string and try to read the new one,
    > eofbit is still set so it fails. In a similar situation, ifstream::eek:pen
    > calls clear when you open a new file. Is there a particular reason for
    > this inconsistency?
    >
    > int n;
    > istringstream i("1");
    > i >> n;
    > i.str("2");
    > i >> n; // fails because we still have i.eof()
    >

    I just a quick look up an online reference for this and according to:
    http://www.cplusplus.com/reference/iostream/istringstream/str/

    str calls rdbuf(), well it say it "effectively" calls rdbuf(), whatever that
    means exactly. If it does call rdbuf then rdbuf should set the ios flags to
    goodbit.
     
    Paul, Apr 16, 2011
    #2
    1. Advertising

  3. Marc

    Paul Guest

    "cg_chas" <> wrote in message
    news:...
    > On Sat, 16 Apr 2011 17:32:58 +0100, "Paul" <> wrote:
    >>> Hello,
    >>>
    >>> I noticed today that istringstream::str, which changes the underlying
    >>> string, does not clear the error state. In particular, if you read a
    >>> string to the end then change the string and try to read the new one,
    >>> eofbit is still set so it fails. In a similar situation, ifstream::eek:pen
    >>> calls clear when you open a new file. Is there a particular reason for
    >>> this inconsistency?
    >>>
    >>> int n;
    >>> istringstream i("1");
    >>> i >> n;
    >>> i.str("2");
    >>> i >> n; // fails because we still have i.eof()
    >>>

    >>I just a quick look up an online reference for this and according to:
    >>http://www.cplusplus.com/reference/iostream/istringstream/str/
    >>
    >>str calls rdbuf(), well it say it "effectively" calls rdbuf(), whatever
    >>that
    >>means exactly. If it does call rdbuf then rdbuf should set the ios flags
    >>to
    >>goodbit.

    >
    > then it goes on to say that, "Notice that setting a new string does not
    > clear
    > the error flags currently set in the stream object unless the member
    > function
    > clear is explicitly called."
    >

    Yes indeed ,
    And having just tried it out on my implementation I can clarify that I get
    the same behaviour.
    I can still retrieve the internal data by calling str() instead of using >>.
     
    Paul, Apr 16, 2011
    #3
  4. Marc

    Arvind Guest

    On Apr 16, 9:49 pm, cg_chas <> wrote:
    > On Sat, 16 Apr 2011 17:32:58 +0100, "Paul" <> wrote:
    >
    > >"Marc" <> wrote in message
    > >news:ioc6ln$8f1$...
    > >> Hello,

    >
    > >> I noticed today that istringstream::str, which changes the underlying
    > >> string, does not clear the error state. In particular, if you read a
    > >> string to the end then change the string and try to read the new one,
    > >> eofbit is still set so it fails. In a similar situation, ifstream::eek:pen
    > >> calls clear when you open a new file. Is there a particular reason for
    > >> this inconsistency?

    >
    > >> int n;
    > >> istringstream i("1");
    > >> i >> n;
    > >> i.str("2");
    > >> i >> n; // fails because we still have i.eof()

    >
    > >I just a quick look up an online reference for this and according to:
    > >http://www.cplusplus.com/reference/iostream/istringstream/str/

    >
    > >str calls rdbuf(), well it say it "effectively" calls rdbuf(), whatever that
    > >means exactly. If it does call rdbuf then rdbuf should set the ios flagsto
    > >goodbit.

    >
    > then it goes on to say that, "Notice that setting a new string does not clear
    > the error flags currently set in the stream object unless the member function
    > clear is explicitly called."


    Why would someone want to set the new string in istringstream object
    and does not want to reset the error flags? If I want to change the
    content of istringstream object, then certainly next step would be to
    read it.
     
    Arvind, Apr 17, 2011
    #4
  5. Marc

    Paul Guest

    "Arvind" <> wrote in message
    news:...
    On Apr 16, 9:49 pm, cg_chas <> wrote:
    > On Sat, 16 Apr 2011 17:32:58 +0100, "Paul" <> wrote:
    >
    > >"Marc" <> wrote in message
    > >news:ioc6ln$8f1$...
    > >> Hello,

    >
    > >> I noticed today that istringstream::str, which changes the underlying
    > >> string, does not clear the error state. In particular, if you read a
    > >> string to the end then change the string and try to read the new one,
    > >> eofbit is still set so it fails. In a similar situation, ifstream::eek:pen
    > >> calls clear when you open a new file. Is there a particular reason for
    > >> this inconsistency?

    >
    > >> int n;
    > >> istringstream i("1");
    > >> i >> n;
    > >> i.str("2");
    > >> i >> n; // fails because we still have i.eof()

    >
    > >I just a quick look up an online reference for this and according to:
    > >http://www.cplusplus.com/reference/iostream/istringstream/str/

    >
    > >str calls rdbuf(), well it say it "effectively" calls rdbuf(), whatever
    > >that
    > >means exactly. If it does call rdbuf then rdbuf should set the ios flags
    > >to
    > >goodbit.

    >
    > then it goes on to say that, "Notice that setting a new string does not
    > clear
    > the error flags currently set in the stream object unless the member
    > function
    > clear is explicitly called."


    Why would someone want to set the new string in istringstream object
    and does not want to reset the error flags? If I want to change the
    content of istringstream object, then certainly next step would be to
    read it.
    xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

    I think the intention is that when str() is used the stream is frozen and
    the stringstream should be treated like a string , not a stream.

    I was searching to find a practical use of stringstream, which I did not
    find, but I found the following little msdn explanation that helped me
    understand it a bit.
    http://msdn.microsoft.com/en-us/library/d653w0hz(v=VS.71).aspx
     
    Paul, Apr 17, 2011
    #5
    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. David
    Replies:
    2
    Views:
    494
    Thomas G. Marshall
    Aug 3, 2003
  2. Brandon
    Replies:
    4
    Views:
    9,191
    John Harrison
    Jun 23, 2004
  3. maestro
    Replies:
    1
    Views:
    317
    Chris
    Aug 11, 2008
  4. newbie30

    *str++ and (*str)++

    newbie30, Aug 12, 2009, in forum: C Programming
    Replies:
    0
    Views:
    821
    newbie30
    Aug 12, 2009
  5. Ethan Furman
    Replies:
    4
    Views:
    264
    Roy Smith
    May 27, 2011
Loading...

Share This Page