Arithmetic extractors

[Benjamin Kosnik]

This in as is...

> First, in most of the do_get() functions (which I have not altered), there
> is a comment to the effect that leading zeros are eliminated. I have taken
> care to do this in _M_extract, although the standard makes no mention of
> it, except for the case of a leading '0' meaning octal if the basefield is
> 0, and "0x" or "0X" meaning hex in similar circumstances. So, am I right
> to do this? 

leading zeros like 00000000000001, are the bits besides hex and octal.
 
so yes, you should be fine.

> The other point I am not sure of is how to recognise white space. The
> standard allows there to be white space after a sign. In order to
> implement this, I just used the function isspace() (in namespace std::, I
> guess - I #include bits/std_cctype.h). Is this appropriate, or should I
> dig into the locale associated with the ios_base& argument __io in order
> to find out what white space is? If indeed I should, can I be helped to
> see how best to do so? Using only public functions, it looks as though one
> has to call getloc(), and then use the ctype facet, etc. etc... If it is
> needed, there is probably an implementation-specific way to do it more
> easily.

there should eventually be an entry in _Format_cache for this

      typedef  _Format_cache<char> __cache_type;	
      __fcache_type* __fmt = __fcache_type::_S_get(__io);
etc.

the other approach, that say istream::sentry uses is to do:

	      const __ctype_type* __ctype = __in._M_get_fctype_ios();
		  __testsp = __ctype->is(ctype_base::space, __c);


> Another couple of points where I think I'm right, but would be happy to
> receive confirmation. As I read it, the standard does not allow for any
> base other than 10 for floating point numbers. 

yep

> Then, if the basefield in the ios_base is zero, rather than oct or dec or
> hex, it seems that the conversion takes place (section 22.2.2.1.2 of the
> standard) as though the format %i were used with stdio. This allows the 0
> prefix for oct and 0x or 0X for hex. In addition, if the basefield is set
> to hex, my reading is that 0x or 0X are admissible even though not
> required.

interestingly, i don't think they are required, but perhaps this is an 
oversight.

> Incidentally, even including the new test,
> make check-target-libstdc++-v3
> now gives complete success with my setup on i686-pc-linux, using the cvs
> gcc/g++ compiler.

yes. thanks. I checked in the revised testsuite for string::find today 
though, so that is a new fail as of today.


thanks again for this work,
benjamin