RE: ICU4C API proposal - int64 support for NumberFormat

If you want something that works like printf, you can use the icuio 
(ustdio) library.  That works with unsigned types (yes, I know that the 
library currently isn't supported and it's a little slow and buggy).  ICU 
3.0 will hopefully start supporting the icuio library.

We'll have to look into completely supporting uint64_t types in the icuio 
library, but that won't happen for 2.8.  We may need to add a uint64_t 
support to NumberFormatting, but I believe we may be able to get around 
that problem.  BigDecimal is just one possible solution to that issue.

George Rhoten
IBM Globalization Center of Competency/ICU  San José, CA, USA




Pete Barber <[email protected]>
11/03/2003 03:02 PM
 
        To:     George Rhoten/San Jose/IBM@IBMUS
        cc:     [email protected]
        Subject:        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