istringstream: str() only works once?

[Brandon]

I'm using an istringstream to convert some integers stored in string
form to integers. However, each integer is stored in a differnt
string. So, I used istringstream's str(string) method for the first
string and then used the >> operator to extract the integer. It
worked just fine. So, on to the second string. I used str(string)
again but this time extraction gave me a seemingly random number
(-858993460). Once an istringstream is initialized or str(string) is
use, can the stream's string not be changed?

-Brandon

 

[John Harrison]

I'm using an istringstream to convert some integers stored in string
form to integers. However, each integer is stored in a differnt
string. So, I used istringstream's str(string) method for the first
string and then used the >> operator to extract the integer. It
worked just fine. So, on to the second string. I used str(string)
again but this time extraction gave me a seemingly random number
(-858993460). Once an istringstream is initialized or str(string) is
use, can the stream's string not be changed?

-Brandon

No, istringstreams work in exactly the same way as other streams.

What happens was that when you read the first integer from the stream you
hit the end of the stream, and so put your stream in an end of file state.
Once this happens, to any stream, nothing more will work on the stream until
you clear the end of file state. Use the clear() method to do this. Here's
some code

#include <iostream>
#include <sstream>
#include <string>

int main()
{
std::string one = "1";
std::string two = "2";
std::istringstream str(one);
int x;
str >> x; // now stream is in end of file state
str.clear(); // clear end of file state
str.str(two);
int y;
str >> y;
std::cout << x << ' ' << y << '\n';
}

john

 

[John Harrison]

What happens was that when you read the first integer from the stream you

hit the end of the stream, and so put your stream in an end of file state.
Once this happens, to any stream, nothing more will work on the stream until
you clear the end of file state. Use the clear() method to do this. Here's
some code

#include <iostream>
#include <sstream>
#include <string>

int main()
{
std::string one = "1";
std::string two = "2";
std::istringstream str(one);
int x;
str >> x; // now stream is in end of file state
str.clear(); // clear end of file state
str.str(two);
int y;
str >> y;
std::cout << x << ' ' << y << '\n';
}

Try the above code without the clear() and it doesn't work. Now replace "1"
with "1 " (note extra space). The extra space means you do not hit the end
of the stream when you read the first integer, and therefore the call to
clear() is no longer necessary.

john

 

[Brandon]

What happens was that when you read the first integer from the stream you

hit the end of the stream, and so put your stream in an end of file state.
Once this happens, to any stream, nothing more will work on the stream until
you clear the end of file state. Use the clear() method to do this.

I hadn't really thought about that but it makes perfect sense. It
does seem like a fairly bad design though. As you said, once you hit
the end of the stream, nothing more will work. That makes perfect
sense for methods like get(), read(), and extraction but if you are
trying to switch the string that it is using, you obviously won't be
at the end of the stream anymore (unless you give it give it "" of
course.)

 

[John Harrison]

I hadn't really thought about that but it makes perfect sense. It
does seem like a fairly bad design though. As you said, once you hit
the end of the stream, nothing more will work. That makes perfect
sense for methods like get(), read(), and extraction but if you are
trying to switch the string that it is using, you obviously won't be
at the end of the stream anymore (unless you give it give it "" of
course.)

It gets worse. Even closing a file and then opening a new one doesn't reset
a streams state. So an error on a previous file will stop a new file working
if you use the same variable.

I agree it seems nonsensical, apparently the situation with file streams is
being reviewed.

john