Re: strtoul etc.

[Nathan Myers <ncm@best.com>]

When you reply to the Libstdc++ list, please do *not* copy both 
to the list and to me.  I have been getting *three* copies of each 
message.  

---

The raw conversion of a sequence of digit characters in memory 
to a number is (as Ulrich has noted) the least of the work to do.
Inlining is irrelevant.

Iostream gets a sequence of characters from an unknown source -- a 
generic iterator.  These are not ASCII characters, but are in an 
encoding defined by the C++ locale object in use.  They are not just 
digit characters either, but contain embedded "group separators" 
(e.g. commas or periods).  They are not "char" characters, but 
"char_type" characters.   They are terminated with a non-digit, 
non-separator character.

The work involved, thus, is to get each character from the source;
identify it -- digit, sign, separator or "other"; identify and 
accumulate its digit value, if any, or note its position; check 
for overflow.  At the end, check grouping.

The "accumulating" part is just multiply-and-add.  Alternatively, it 
means identifying the corresponding digit character in the _current_
global C Library locale's encoding, and adding that to a buffer to 
pass to strtoul.  The work done in strtoul is similar to what was 
already done, but using the C locale's encoding.  It must parse out 
the characters, convert them to digit values, accumulate them.

There is much about parsing numbers that can be specialized out for
common cases, to avoid overhead when using the default encoding, no 
digit grouping, and/or a known iterator type (e.g. pointer,
istreambuf_iterator, basic_string::iterator).  Using strtoul just 
adds a complication: what if the global C locale encoding changes 
*while* you accumulate digit characters for strtoul?

Nathan Myers
ncm@cantrip.org