🚀 go-pugleaf

In article KAA12047@netcom22.netcom.com, cpp@netcom.com (Robin Rowe) writes:
>When using istream, numbers aren't parsed consistently by different
>compilers. For instance, in g++ inputting "95 09 23" is parsed as
>{95,0,9,23}, while the SGI C++ compiler will read it as {95,9,23} as one
>would tend to expect. Which is right, and if the former how is this
>"feature" turned off to get the latter result? 

The question is whether the istream is initialized to decimal conversion
mode or not. If initialized to decimal mode, "09" is read as "9". If not,
the same rules as for literals in C or C++ is used: a leading "0X" or "0x"
means hex conversion, otherwise a leading "0" means octal conversion.
Thus, since "9" is not an octal digit, "09" is interpreted as two values,
"0" and "9", with istream input.

The draft standard section on iostreams is in severe disarray currently,
and I can't tell what the default should be. I don't remember what the
original AT&T documentation said what the default should be.

The solution is simple: set the conversion base explicitly to decimal
at program start if you want that as the default
	cin.setf(ios::dec, ios::basefield);
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <446i9t$9m2@engnews2.Eng.Sun.COM> clamage@Eng.Sun.COM
(Steve Clamage) writes:

|> In article KAA12047@netcom22.netcom.com, cpp@netcom.com (Robin Rowe) writes:
|> >When using istream, numbers aren't parsed consistently by different
|> >compilers. For instance, in g++ inputting "95 09 23" is parsed as
|> >{95,0,9,23}, while the SGI C++ compiler will read it as {95,9,23} as one
|> >would tend to expect. Which is right, and if the former how is this
|> >"feature" turned off to get the latter result? 

|> The question is whether the istream is initialized to decimal conversion
|> mode or not. If initialized to decimal mode, "09" is read as "9". If not,
|> the same rules as for literals in C or C++ is used: a leading "0X" or "0x"
|> means hex conversion, otherwise a leading "0" means octal conversion.
|> Thus, since "9" is not an octal digit, "09" is interpreted as two values,
|> "0" and "9", with istream input.

|> The draft standard section on iostreams is in severe disarray currently,
|> and I can't tell what the default should be. I don't remember what the
|> original AT&T documentation said what the default should be.

|> The solution is simple: set the conversion base explicitly to decimal
|> at program start if you want that as the default
|> 	cin.setf(ios::dec, ios::basefield);

I would agree that it is *always* a good idea to set the fmtflags to
the value you want; if nothing else, this makes your code more robust.
(Imagine what happens if someone inserts a debugging output in hex in
front of your output.)

Still, in the public draft (27.4.3.5), it states that after the
constructor for ios_base, ``flags() == skipws | dec''; in table 73,
this corresponds to the scanf conversion %d or %u.  Although I was
unable to find a statement to the effect in the man pages, the cfront
based compilers to which I have access all initialize fmtflags to this
value, too (and I suppose that at least one of them has the original
AT&T implementation).

One thing that does bother me in the standard: suppose I do:

	cout.setf( ios::hex | ios::oct , ios::basefield ) ;

My interpretation of table 73 is that this is fully defined, legal,
and has the same effect as:

	cout.setf( ios::dec , ios::basefield ) ;

Wouldn't it be better if the first form were declared illegal: either
undefined or better, an exception should be thrown?

Obviously, I don't really expect programmers to write the first, but I
do imagine that, separated by many lines of code (or in separate
modules), the following to occur:

	cout.setf( ios::hex ) ;
	//  ...
	cout.setf( ios::oct ) ;

I think that there is a chance for subtle errors here, and would
prefer to at least allow (if not require) the implementation to trap
them.
--

James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]