RE: ICU4C API proposal - int64 support for NumberFormat

>>Right now, the formatting code in i18n doesn't support unsigned types, 
>>including uint32_t.  I don't see a reason to change that model.
I think one of the weaknesses of ICU is that there is no way in the resource
catalog and MessageFormat() to specify unsigned versus signed values.  It
makes it harder to use ICU to replace printf()/iostream in a C/C++ app.

I've wrapped ICU and used by own insertion parameter syntax in the resource
files so every type supported by printf/iostreams can be used in the
catalog.  MessageFormat does not use this syntax and I have had to write my
own param. substitution code.  I use all the ICU formatting code for each
parameter so this way I can be sure that if an unsigned long is passed in it
is handled as one.

>>If you're really need the range of a uint64_t type, you probably really 
>>need the range of the BigDecimal class (not available in ICU4C yet).
Yes, that's the obvious extension to the current implementation but
BigDecimal would be a s/w implementation whereas an explicit method for
uint64_t wouldn't.

>>My opinion is that ICU should support 64-bit types the same way as int32_t

>>types are supported.  I don't see a compelling reason to have yet another 
>>API to support uint64_t that does almost the same thing.
I think ICU should try to mirror printf/iostreams and support the basic OS
types inc. hex/octal formatting via catalog specification rather than
treating them all as number.  The extended types, i.e. currency, percent
plus date and time are excellent but support for the basic types and
formatting options could mean an end to printf!

Thanks,

Pete