strtoul etc.

[Nathan Myers <ncm@cantrip.org>]

Seeing all this apparatus being constructed to use C-library
facilities to implement iostream numeric conversion, badly, is 
giving me hives.

The C++ code knows all the formats required, already.  To construct
a format string so that a C library function can puzzle out the
format *again* is madness.

Using the strtoul() family for conversion is just wrong.
While filling the buffer to pass to strtoul, you have already
done all of its work except for the most trivial part -- a
multiply-and-add.  Furthermore, the C functions do not detect 
overflow, where C++ is required to detect and report overflow 
and similar errors, so besides being slower, it's wrong.

The C++ code must discard the leading zeroes itself because 
there is no limit on how many there might be.  Three thousand 
zero digits followed by a one is legal input, and should not be
treated as an error (or a handy stack smash).

If the C and C++ libraries must share conversion code, they 
should share lower-level code that doesn't introduce inefficiencies
into the C++ library.  Our goal for C++ should not be to make it 
slower than equivalent C, or "not much slower than" equivalent 
C, but always at least as fast as equivalent C, and *usually*
faster.  We're all more familiar with the C library; that is no 
excuse for sloppiness.

This is not to say that expedient temporary hacks should not be 
used; only that they should be marked "XXX" and recognized as 
scaffolding to enable testing of the rest of the library, and
not as finished code.

Nathan Myers
ncm@cantrip.org