Boost logo

Boost :

From: mfdylan (dylan_at_[hidden])
Date: 2002-01-24 01:55:05


--- In boost_at_y..., Karl Nelson <kenelson_at_e...> wrote:
>
> That would not well serve the purpose of allowing
internationalization.
> String translation services use printf. It is a large standard
which
> we really should obey. This point has been discussed multiple
> times on the list. Positional simply does not serve the needs of
> a formating tool.
>
> > By the way, Robert's approach doesn't mention about how to write

Surely it's fair to assume most translation services understand the %
1 %2 %3 style? It's used by the Win32 FormatMessage API if nothing
else. As for the problem of how to deal with a number directly after
the digit, has anyone seriously ever needed more than 9 positional
parameters in a sentence? And does it really happen so often that
breaking the string up into two is going to cause a major problem?
If not, then you just take the first digit after the % and you're
done. Simplifies parsing, and the pretty rare cases where you might
want a fixed number directly after a positional parameters aren't
likely to upset anyone too much. If they do, then make the number a
parameter too.

So
"Renaming file %1 in folder %2 to %12. OK?"

becomes

"Renaming file %1 in folder %2 to %1%3. OK?"

Even if the number is always '2' for now, there's a moderate chance
in the future it might change, so inserting dynamically at runtime is
doing no harm.

As for the formatting options (width/precision specifications and so
forth), I really can't see a lot of point of encouraging continued
use of the cryptic printf-style, which can hardly make translators'
jobs easier. The only reason I can see for keeping them part of the
string is the possibility that in you want different hardcoded
specifications across multiple languages. I'm willing to hear a
reasonable justification of why this is necessary (as opposed to
dynamically determined specs where they may need to be different for
different languages), but I certainly can't think of any.

As for using [], I was only finally warming to using % as an insertor
when the [] idea was sprung on us all.

Now we are supposed to something like write

format("array\[[1]\] = [2]") [i] [array[i]];

as opposed to

format("array[%1] = %2") % i % array[i];

At least using '%<n>' the only time you'd require escaping of '%' is
if you actually want to display % followed by a number - and %
generally goes at the end of a number so that's pretty unlikely. I
guess something like:

"n mod 2 (notated n%%2) returns the least significant bit"

I'd prefer

format("array[%1] = %2", i, array[i]);

Although if you allow for manipulators between parameters, even with
only 9 parameters you would have to support a helluva lot of template
variants. And I guess it's handy to be able to insert parameters one-
by-one if necessary. To be honest I never really understood the
argument against using '<<' - I assume the only reason was that the
statement

cout << format("array[%1] = %2") << i << array[i] << ".\n";

Could either be an error (inserting too many parameters), or an
intended insertion of ".\n" into the stream after the formatted
message. I probably opt on the safe side and say it's error and
require extra parentheses:

cout << (format("array[%1] = %2") << i << array[i]) << ".\n";

I think I showed in another post how this can implemented with
minimal code and fairly efficiently.

Dylan


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk