Re: ICU4C API proposal - int64 support for NumberFormat

re: streams and I/O
The poor support for unicode in streams is one of the biggest disadvantages of
C++.

In particular there are difficulties with both unicode filenames and
reading/writing data as UTF-16 at least in the Microsoft platforms. I am less
familiar with streams on the others, but I am told that due to the inadequacies
of the C++ standard in this regard, portability is a significant problem.

So if ICU had a robust, portable and supported alternative solution, it could
be a compelling argument for its usage.
I would give that a lot of weight in release planning.

Separately, I thought Pete's arguments for 64-bit ints were reasonable, but I
don't have a sense for the demand.

tex

George Rhoten wrote:
> 
> 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
> 
> _______________________________________________
> icu mailing list
> [email protected]
> http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu

-- 
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898   mailto:[email protected]
Xen Master                          http://www.i18nGuy.com
                         
XenCraft		            http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------