🚀 go-pugleaf

In article <9526103.9614@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU
(Fergus Henderson) writes:

|> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

|> >fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
|> >
|> >|> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
|> >
|> >|> >Normally, the format string in production code
|> >|> >will not be a string literal, but rather something read from a
|> >|> >configuration file, dependant on the locale setting.
|> >
|> >|> That has not been my observation.
|> >
|> >Are Australians as unaware of the existance of the rest of the world
|> >as Americans are?

|> Certainly not! ;-)

Actually, I never really believed it.

From my discussions on the net, I get the impression that there are
three distinct attitudes to internationalization:

1. The North American one.  It doesn't exist.  (With some important
exceptions: Sun, HP and Microsoft, amongst others, make a great effort
in this regard.  And IBM almost invented the concept.)

2. The European one: for the most part, we use ISO latin-1, use
multi-lingual messages, and think that we're international because of
it.  (I suspect that Latin America would also be in this group, but to
date, I've had no real contact with Latin American programmers.)

3. The rest of the world (including Australia).  They know that
internationalization is difficult, requiring wchar_t, code translation
on input and output, and so on.

|> Nevertheless, almost all of the programs I have seen produce messages
|> in only one language.

So you're a systems programmer, like me:-).

|> This includes programs such as gcc (and indeed
|> almost all of the GNU programs);

GNU doesn't have to worry about selling in a competative market.  But
I believe that there are internationalized versions of emacs, and
perhaps other GNU tools, available.

|> CHRIS (a now million-line COBOL
|> personell/payroll program that I worked on about 7 years ago);

Bookkeeping programs of any sort are almost always uni-lingual (except
maybe in Belgium or Switzerland).  Accounting practices and laws vary
too much from one country to the next.

|> the
|> Mercury compile (the program I've been working on for the last couple
|> of years); Linux - even though Linux's development was started by Linus
|> Torvalds, a citizen of Finland whose native toungue is Swedish, if I
|> remember the details right), and even though Linux is used in a variety
|> of countries whose primary language is not English; and a variety of
|> other programs, both commercial and free.

Linux is an OS.  Normally, if the applications are correctly written,
the user should never see a message from Linux.

On the other hand, Linux competes on price, not service.  Solaris *is*
multi-lingual.

|> The reason for this is simple: the cost of producing multi-lingual programs
|> usually exceeds the benefits.

For the producer.  For the (non-English speaking) user?

This will depend a lot on local customs.  In Scandinavia, Holland and
to a lesser degree, Germany, English is OK at the systems level (OS
and compilers), but not at the user level.  (I believe Scandinavia
even has laws to this effect.)  In France, on the other hand, French
is the standard language of computers, and there is a definite demand
for system software with messages in French.

|> >(This really doesn't have much
|> >to do with Fergus' point, but it is a pet peave of mine.)

|> I've noticed ;-)

The French influence:-).

|> >|> What is relevant is that in many C programs,
|> >|> most calls to printf() have a string literal as the first argument; if
|> >|> optimizing those calls to printf() is likely to speed up the program or
|> >|> reduce code size, then any good optimizing compiler should do so, just
|> >|> as any good optimizing compiler should optimize division by a
|> >|> constant.

|> >Optimization isn't free.  I would argue against this optimization on
|> >two grounds: 1) It only affects a limited number of programs,
|> >generally, test programs or other quick hacks (let's face it, I'll put
|> >a constant string in a printf, too, if the program is only going to be
|> >run once, or if I'm the only person who will see the output), and

|> I don't agree with this.  As noted above, in my experience the vast
|> majority of programs that use printf() use string literals for the
|> format string.  While I'm aware that my experience is unlikely to be
|> reflective of the situation world-wide, it does nevertheless mean
|> that this is true for at very least a significant proportion of all
|> programs.

I would contend that your experience (and to some extent, mine) is
limited to certain domains.

I do see a definite demand for mult-lingual software in many fields.
Generally, with the possible exception of France, people who develop
software can read fluent English; messages targetted to program
developpers can generally be in English.  Similarly, there are a few
programs which are so local as to be totally unusable in an
international environment.  After all, there really isn't a large
demand for a program to calculate American tax returns in French.

Most of the rest should probably be multi-lingual.

Maybe the real reason why I don't want compilers to optimize this is
that it would give people yet another excuse for not handling the
problem correctly (for my definition of correctly).

|> >2) I am almost willing to bet that the time spent in parsing the printf
|> >string is totally negligible next to the time spent in conversion and
|> >output (if this wasn't the case, iostream, which doesn't parse, would
|> >be significantly faster than printf). Also: I would hope that the
|> >number of C++ using printf is very small anyway.  (This is
|> >comp.lang.c++, not comp.lang.c.)

|> This is most likely true.  That's why I carefully said "_if_ optimizing
|> those calls to printf() is likely to speed up the program or
|> reduce code size ...".  So I agree with your conclusion - I just
|> disagree with some of your arguments.

|> >If the compiler is going to spend time optimizing (and the compiler
|> >writer is going to spend time developing the optimization), then I'd
|> >rather see it go to things that will really improve performance.

|> Agreed.

|> >|> The fact that there may be many programs that don't use
|> >|> division by a constant or printf() with a string literal for the format
|> >|> string does not imply that compilers should not optimize those
|> >|> constructs.

|> >Actually, I would argue that it does, in so far that optimization
|> >costs, and programs that don't use these features shouldn't have to
|> >pay the cost.

|> The cost of an optimization such as the above that is not applied is
|> pretty negligable; if it provides significant benefits for some programs,
|> then it should be included.  These days, good optimizers need to include
|> a wide variety of optimizations that are only applicable to particular
|> circumstances.  For any given piece of code, only a small portion of
|> them may be applicable.  Nevertheless, such optimizations are necessary
|> for good performance.  If optimizations were not implemented simply
|> because they might not apply to most pieces of code, you would end up with
|> a poor optimizer.

I'll grant you this.  After all, there's a lot of optimization out
there for floating point, yet most programs never use floating point.

I think that there is a second point to consider: how important is
speed for the applications improved by the optimization.  The reasons
so much effort has gone into floating point optimization isn't that
all programs use it, but that many of those that do tend to be the
ones that need all of the cycles they can get.  I suspect that this
would be still another argument about optimizing a constant string in
a printf, but why flog a dead horse.  I think Fergus would agree that
most compilers still have more pressing problems (like generating
correct code, or conforming to all the new aspects of the draft
standard).
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung