[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

Stream extraction failing

newbarker

9/9/2008 10:01:00 AM

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

Alf P. Steinbach

9/9/2008 10:33:00 AM

0

* newbarker@gmail.com:
> 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?

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?

newbarker

9/9/2008 10:48:00 AM

0

On 9 Sep, 11:32, "Alf P. Steinbach" <al...@start.no> wrote:
> * newbar...@gmail.com:
>
>
>
>
>
> > 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?
>
> 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

utab

9/9/2008 3:54:00 PM

0

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

9/10/2008 7:59:00 AM

0

On Sep 9, 5:53 pm, utab <umut.ta...@gmail.com> wrote:
> 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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze

9/10/2008 8:19:00 AM

0

On Sep 10, 9:59 am, James Kanze <james.ka...@gmail.com> wrote:
> On Sep 9, 5:53 pm, utab <umut.ta...@gmail.com> wrote:
> > 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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

utab

9/10/2008 5:18:00 PM

0

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

9/11/2008 7:52:00 AM

0

On Sep 10, 7:18 pm, utab <umut.ta...@gmail.com> wrote:
> 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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34