Re: To go with Go or C/C++?
On Sunday, May 12, 2013 9:45:45 PM UTC+1, Paavo Helde wrote:
James Kanze <james.kanze@gmail.com> wrote in
news:863e5c53-f180-4bf6-90d4-1bd562a47f14@googlegroups.com:
On Sunday, May 12, 2013 12:42:54 AM UTC+1, Paavo Helde wrote:
James Kanze <james.kanze@gmail.com> wrote in news:d0cdc795-7f7b-4133-
aaf4-868d80ab5869@googlegroups.com:
On Friday, May 10, 2013 6:09:27 PM UTC+1, Scott Lurndal wrote:
Paavo Helde <myfirstname@osa.pri.ee> writes:
[...]
Since most of my programming is on linux, I use gcc's
__attribute__((printf,...)) to let the compiler ensure
type-safety,
Except that this feature doesn't work, since you almost never
have format strings that are compile time constants.
If the format string is not a compile time constant then it is indeed
hard to use the printf-style formatting because it would become
cumbersome to ensure that even the number and order of the arguments
match (all possible variants of) format strings, not to speak about
the type safety.
About the only time I've had to output compile time constants
was when doing programs for some government authority. If
you're code implements French tax laws, then you probably don't
have to worry about outputting in German. For almost everything
else, output strings have come from external, language dependent
files. (Of course, if you really have to support natural
languages in all of there detail, rather than just translating a
few simple messages, you'll need a separate DLL for each
language, so you could end up with compile time constants there
as well.)
My feelings about i18n are mixed. On one hand it would be nice to
communicate with the software in my own language. On the other hand the
general state of the art seems to be so bad (e.g. half of menu items in
broken native language, and half in English) that I almost always switch
the interface to English.
That's generally a problem in technical software. Each
translator invents his own translation for newer technologies,
or each company develops its own standards. (I know that when
I worked at Siemens, we often spoke of Siemens-Deutsch: a set of
translations for things like cursor which were only really known
within Siemens, and not even always then.)
In my mind, converting some software to a native language should be done
well or not done at all. With the kind of software we are making, I
cannot see the former happen in the next 30 years, for various reasons.
And by then the Google Glasses should be advanced to the Babel Fish level
already so there should be nothing to worry about.
I guess this all depends on the scope of the application. And yes, our
software is used in France and China. We are taking care that if someone
wants to write filenames or dataset annotations in hieroglyphs he can do
so. However, the error messages will still be in English.
This is probably acceptable for some types of technical software
(e.g. a C++ compiler). For most things, however, you'll want
a local language interface, and most of the companies I've
worked for have insisted on it (including when I was working on
compilers for Siemens).
Logging is one case where you often can use a single language.
It's also a case, however, where using printf would be a
maintenance nightmare, since you're outputting internal types,
which could easily change.
That's why one needs to use C++ typesafe equivalents of printf.
Or simply `std::ostream`. It's much better adopted to the
different sinks you're likely to encounter. Logging almost
always means custom streambuf's.
Even at the time and place where it was invented, printf was a
step backwards, compared to other languages. The "motivation"
behind it is, I suspect, the desire to not make IO part of the
language, but strictly a library component. Realistically, I
think we can call it an experiment which failed. C++ manages to
make IO purely library, but only because it has overloading and
polymorphism.
I think you are mixing up formatting and IO, these are quite orthogonal
topics.
Not for the printf family.
IO is done by OS and is mostly binary, it sees only bytes and
does not care about types.
Perhaps I should have said sinking and sourcing rather than IO;
I thought the implication was obvious. With the printf family,
you have to use different functions for different sinks and
sources; with iostream, it's all handled in the concrete
strategy of the streambuf.
Nevertheless, many newer languages have borrowed the printf concept,
primarily because of its concise syntax. As soon as the language is
introspective enough to know the types of its variables, one can make a
typesafe printf, removing its largest drawback in C.
Typesafety is only one of the problems of printf. The lack of
extensibility is an issue anytime you can define your own
types. Or you need to define your own sinks and sources.
Which means pretty much always.
--
James