ICU4 API proposal: sprintf/scanf-like support in 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=844

although I doubt the author had this in mind!



__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html