RE: ICU4C API proposal - int64 support for NumberFormat
George Rhoten <[email protected]>
| Newsgroups | gmane.comp.lib.icu.general |
|---|---|
| Message-ID | <OF738BEC05.F6595931-ON86256DD3.007A6144-88256DD3.007C4E66@us.ibm.com> |
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. 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). 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. George Rhoten IBM Globalization Center of Competency/ICU San José, CA, USA Pete Barber <[email protected]> Sent by: [email protected] 11/03/2003 02:14 PM To: George Rhoten/San Jose/IBM@IBMUS, [email protected] cc: Subject: RE: ICU4C API proposal - int64 support for NumberFormat >>The main issue for me is not HP-UX aCC uint64_t support, but it is keeping >>the ICU4C and ICU4J APIs in sync. I agree that it's nice to keep things in sync. But what does this functionally achieve. When I submitted my changes to you, you said that I would need to provide full support, i.e. parsing/input. Surely FULL support implies unsigned as well as signed 64bit ints. Not having unsigned will mean for some apps. (mine at least:-)) that there ISN'T 64bit int support. Thanks, Pete Barber _______________________________________________ icu mailing list [email protected] http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu