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

[utab]

On Tue, 09 Sep 2008 12:32:33 +0200, Alf P. Steinbach wrote:

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. :-)

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...

[James Kanze]

On Sep 9, 5:53 pm, utab <[e-mail]:

On Tue, 09 Sep 2008 12:32:33 +0200, Alf P. Steinbach wrote:

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. :-)

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 (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Sep 10, 9:59 am, James Kanze <[e-mail]:

On Sep 9, 5:53 pm, utab <[e-mail]:

On Tue, 09 Sep 2008 12:32:33 +0200, Alf P. Steinbach wrote:

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. :-)

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.)

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 (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[utab]

On Wed, 10 Sep 2008 00:59:15 -0700, James Kanze wrote:

>
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.)

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.

Thanks

[James Kanze]

On Sep 10, 7:18 pm, utab <[e-mail]:

On Wed, 10 Sep 2008 00:59:15 -0700, James Kanze wrote:

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.)

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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]