🚀 go-pugleaf

In article <9525008.24470@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:

|> >matt@godzilla.EECS.Berkeley.EDU (Matt Austern) writes:
|> >
|> >|> There's nothing wrong with a C++ implementation parsing
|> >|> printf's format string at compile time, doing error checking to
|> >|> make sure that there aren't any type errors, and putting in the
|> >|> appropriate low-level calls.
|> >
|> >|> I don't know the names of any implementations that actually do this, but
|> >|> I strongly suspect that there are some.
|> >
|> >Actually, I doubt it.  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?

|> >Or do you really think everyone in the world can read English
|> >fluently.

|> That's not relevant.  The issue is optimization, not
|> internationalization.

It's relevant in the sense that it is the reason why almost none of
the programs written be me or my collegues use constant strings in
printf.

It's interesting to note that even the term `internationalization' is
American-centric, as though there is something exotic, or odd, about
not using English (and only English).  To me, the first step of
`internationalization' *is* to use English.  (I use French and German
locally.  And yes, it means that *every* program I write, practically,
must be able to handle both of these languages.)

I would like to stress this difference.  If you are really concerned
about internationalization, that is: writing programs which work in
different linguistic and cultural environments, then you use wchar_t,
and forget about things like ctype.  And yes, this is difficult, and
for many programs, not worth the effort.

But there are a lot of us who only need the program to work in one or
two languages.  This isn't `internationalization' per se, since only
one nation (or group of nations, e.g.: the European Community) are
involved.  But we still have to jump through hoops to make our program
work with e.g.: accented characters.  (This really doesn't have much
to do with Fergus' point, but it is a pet peave of mine.)

|> 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 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.)

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.

|> 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.
-- 
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