I am no expert, but if they teach STL for C++ why not use that instead which
is suppose to be type cast safe, instead of the older printf mechanism. I
don't want to start a war on what the best method is. But just wanted to
understand. Or would the cost in time be too high to convert everything?
my 2c
Theunis
On 19/02/2008, Klaus Schmidinger <[EMAIL PROTECTED]> wrote:
>
> On 02/19/08 21:26, Ludwig Nussel wrote:
> > Klaus Schmidinger wrote:
> >> Apparently there are macros for this, like PRId64 and such.
> >> But i don't like having to write something like
> >>
> >> int64_t n = ...;
> >> printf("Some number %" PRId64 "\n", n);
> >>
> >> Don't know if the gettext mechanisms would be able to handle
> >>
> >> tr("Some number %" PRId64 "\n")
> >>
> >> I wonder why there ar no proper format specifiers for this.
> >> Or are there?
> >
> > The gettext info page says:
> >
> >> A similar case is compile time concatenation of strings. The ISO C
> >> 99 include file `<inttypes.h>' contains a macro `PRId64' that can be
> >> used as a formatting directive for outputting an `int64_t' integer
> >> through `printf'. It expands to a constant string, usually "d" or "ld"
> >> or "lld" or something like this, depending on the platform. Assume you
> >> have code like
> >>
> >> printf ("The amount is %0" PRId64 "\n", number);
> >>
> >> The `gettext' tools and library have special support for these
> >> `<inttypes.h>' macros. You can therefore simply write
> >>
> >> printf (gettext ("The amount is %0" PRId64 "\n"), number);
> >>
> >> The PO file will contain the string "The amount is %0<PRId64>\n". The
> >> translators will provide a translation containing "%0<PRId64>" as well,
> >> and at runtime the `gettext' function's result will contain the
> >> appropriate constant string, "d" or "ld" or "lld".
> >
> > So translations should still work. The ugliness of those macros remains.
>
>
> I agree. I wonder who came up with this <adjective censored> idea?
> Why would somebody totally break the printf mechanisms and introduce
> such ugly macros?
>
> I really hope we can avoid this insanity in VDR...
>
>
> Klaus
>
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
