Re: Arithmetic extractors

[Nathan Myers <ncm at cantrip dot org>]

On Mon, Jun 19, 2000 at 10:28:54PM -0700, Benjamin Kosnik wrote:
> > 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.

Note that digit groups and digit group separators mixed into leading 
zeroes must be counted and handled.  Also, note that an unlimited 
number of leading zeroes are allowed.  

However, you don't have to save the zeroes, or remember more group 
counts than are specified in the grouping string.  That is, a 
circular buffer of group sizes encountered, along with the max 
and min group sizes discarded, is sufficient to perform all checking.  

You can allocate (and grow, as needed) that circular buffer 
as a vector<> in the format-cache structure.

Sequences of trailing digits in floating-point values can get 
quite long as well; e.g. 345,234,345,345,345,345,345,345,345,345
is a valid float value, even though the lower digits get discarded in
the end.
 
> > 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);
 
It would be a lot better to use the vector form of is() for the
common case where you have a streambuf buffer to scan through.  
A couple of extensions to basic_streambuf, __scan_is() and 
__scan_not(), would be the clean way do it.  istreambuf_iterators
are currently very slow.
 
> > 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.

No, they are absolutely not required.  

Nathan Myers
ncm at cantrip dot org