Stream extraction failing

[newbarker]

Hello all,

#include <sstream>
#include <iostream>

int main()
{
std::istringstream iss("6.5e");
double size;
char fit;
iss >> size >> fit;
std::cout << "size(" << size << "), fit(" << fit << ")" << std::endl;
}

This program doesn't extract the elements okay (apparent garbage
output) but if the input stream is 6.5d it does. I figure this is
because the extraction operator thinks it's going to have a number
like 6.5e+12??? Is there a way I can turn this feature off and make it
extract 6.5 and d separately?

Regards,

Pete

 

[newbarker]

* (e-mail address removed):









Not that I know: it amounts to defining new syntax for double literal.

It might be possible to fool stream into thinking 'e' is separator, but that
would be very ugly hack, and probably not well-defined by standard.

I'd just use a loop to copy characters while digit or radix point; much less
work than finding out if hack works and whether supported by standard.

Cheers & hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?- Hide quoted text -

- Show quoted text -

I thought there might be a way because when you're inserting into a
stream, you can use std::fixed so it outputs in fixed-decimal
notation. Of course it didn't work on extraction.

I'll do the loop as you suggest.

Many thanks,

Pete

 

[James Kanze]

Hi, just a bit of playing with the simple code,

double a = 4.3e;

is not a valid definition because there should be an exponent
after the 'e', but is there sth else defined for istringstream
class, because it can extract 6.5e even if it is not a valid
expression outside the double quotes, trying a string such as
6.5e is extracted as 6.5 only and 6.5ee as 6.5 and e...

I don't think that this is right, although interpreting the
standard literally... It looks like there's an error in the
standard. This is certainly not what one would want or expect;
a stream should never silently drop a non white space character.
(Most implementations do the right thing, and set fail in this
case.)

 

[James Kanze]

I don't think that this is right, although interpreting the
standard literally... It looks like there's an error in the
standard. This is certainly not what one would want or expect;
a stream should never silently drop a non white space character.
(Most implementations do the right thing, and set fail in this
case.)

Just a follow-up: there is an active DR on this: DR23 (one of
the oldest around). It is apparently still under review. (The
actual DR concerns behavior in case of overflow, but the
proposed changes in wording would require reading something like
"1.23ex" into a floating point to set failbit and store 0.0 in
the result.)

 

[James Kanze]

It was also strange for me, but I could not get the conclusion
from your explanation, I got the previous results with g++,
intel compiler reads another character into(unrecognizable on
cout output, but there is sth) 'fit()' which is given in the
original code.

See my follow-up to my own posting. This is clearly an error in
the standard; g++ simply implements exactly what was written,
even though it was obviously wrong, and inconsistent with
existing practice. All of the other compilers I have access to
(VC++, Sun CC, both with the RogueWave library and with STLPort)
behave "correctly"; that is, they do what one would expect, and
what the proposed resolution to the DR requires, and set
failbit.