Re: ICU4 API proposal: sprintf/scanf-like support in formatters

[George R. <gr...@us...>]

This seems like a lot of duplication of effort.  If you want a full POSIX=20
formatting pattern, why not just extend the current icuio library.  The=20
icuio library is better suited for migrating C/C++ to use Unicode support.

For the C++ formatting API, I was thinking more of something like the JDK=20
1.5 implementation pattern formatting specification, which is way better=20
suited for this type of formatting.  You may want to look at the=20
java.util.Formatter class for what I was thinking of.  I like the design=20
much better.  It's also better suited for date/time formatting than the=20
POSIX API.

Creating a new formatting specification, as you proposed it, would create=20
yet another mutant formatting spec.  I was hoping not to create a new=20
format for everyone to learn.

George Rhoten
IBM Globalization Center of Competency/ICU  San Jos=E9, CA, USA
ICU main website: http://oss.software.ibm.com/icu/index.html




"Edward J. Batutis" <ejb...@ya...>
Sent by: icu...@ww...
02/11/2004 08:12 AM
=20
        To:     ic...@ww...
        cc:=20
        Subject:        ICU4 API proposal: sprintf/scanf-like support in=20
formatters



This proposal covers a set of APIs that would be used
mainly to incorporate sprintf-like formatting into
MessageFormat and make scanf-like parsing available.
Motivation: ease of converting old C/C++ code to ICU
that uses sprintf/scanf. The formatting/parsing
functionality currently available does not cover the
functionality available via sprintf/scanf and there
does not seem to be an easy way to extend the current
classes to do this.

I don't know of a name for the pattern 'language' used
in printf/scanf, so I'm calling it an 'fpattern'
(printf/scanf Format PATTERN). If there's a generally
accepted name, I'd love to know what it is.

I propose adding two utility classes - a class to
format/parse strings with an fpattern -
FPatternStringFormat - and one for numbers -
FPatternNumberFormat. These would be derived from
Format.

The fpattern handled by these classes would be the
sprintf/scanf pattern from the '%' to the type letter
('d' for example). The idea is to simplify the initial
implementation. This restriction could be lifted
later.

The behavior of the pattern in terms of formatting and
parsing strings would be indentical to printf/scanf.
Initially at least, the details of the behavior might
be platform-dependent since the easiest way to
implement this feature is to use the platform's
sprintf/scanf.

MessageFormat would be extended to support these
classes in the following manner. Examples:

{0, number, fpattern, %8u}
{0, number, fpattern, %8.2f}
{1, string, fpattern, %-10s}

The eventual ideal would be to support the full posix
fpattern described here:

http://www.opengroup.org/onlinepubs/007908799/xsh/fprintf.html

modified to make sense in this context. Some things
that would need to change or be left out: the 'arument
number' (that is what MessageFormat is for!), the
field width substitution ('*' - there's only one
number to format with), '%s' taking a char pointer,
and perhaps a few others. This will need further
analysis.

In the short run any implementation would probably be
a small subset of the above Posix functionality, but
it would support full internationalization of decimal
separators, etc., as needed.

This proposal is most closely related to j-bug 844:

http://www.jtcsv.com/cgibin/icu-bugs?findid=3D844

although I doubt the author had this in mind!



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
icu mailing list
ic...@os...
http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu