Re: To go with Go or C/C++?
On Sunday, May 12, 2013 12:42:54 AM UTC+1, Paavo Helde wrote:
James Kanze <email@example.com> wrote in news:d0cdc795-7f7b-4133-
On Friday, May 10, 2013 6:09:27 PM UTC+1, Scott Lurndal wrote:
Paavo Helde <firstname.lastname@example.org> writes:
Since most of my programming is on linux, I use gcc's
__attribute__((printf,...)) to let the compiler ensure
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
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
This does not mean that I would advocate using gcc-s __attribute__. First
it is non-portable, second it requires special attention from the
programmer, and third, the programmer is still not relieved from the duty
of taking care of the low-level type correctness and needs to type in
explicit casts and conversions when needed. A C++ typesafe solution can
do all this work for the programmer and convert everything automatically.
Admitted, the printf-style formatting is a limited tool, but in its
limited area it does its job well. We are using it mostly for composing
error and log messages, so there is no fancy object serialization or
stream filtering involved.
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.
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