[haiku-commits] Re: haiku: hrev44929 - in src: kits/media apps/sudoku
- From: pulkomandy@xxxxxxxxxxxxx
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Sat, 01 Dec 2012 09:47:02 +0000
On 2012-12-01 at 05:15:22 [+0000], looncraz <looncraz@xxxxxxxxxxx> wrote:
> hmm... I do - not - know...
>
> seems there must be some point at which the type is identifiable... but
> I'm not terribly familiar with how it works down deep (always meant to
> look at it though...).
Sorry but no. there's no way, and that's the point of using %d, %ld, etc
instead of just % for everyone.
The arguments are basically just mashed together on the stack, and only the
format specifiers tells printf how much space they take.
If you think the solution with the B_PRI* macro is ugly, just use
std::cout << "The C++ way is " << 10 << " times better\n";
Since C++ is type-safe, cout knows about the argument type (and size) and
will do the right thing.
I see a problem with both approaches anyway : this prevent the locale
catalogs from working ! With cout, the string is broken into pieces so it
makes life harder for translators guessing what goes where, and possibly
prevents a proper translation (for example in Yoda language, you'd need
something like :
std::cout << 10 << " times better, the C++ way is\n";
notice the lack of any string before the number).
In the printf case, the macro will be preprocessed before collectcatkeys is
done, as a result the translator will get a string with a %d or %ld or ...
inside and the resulting catalog will be different on 32 and 64 bit platforms.
Fortunately, this is already solved by the way our localization are done.
We use the following scheme :
BString message(B_TRANSLATE("The Haiku way is %times% times better"));
message.ReplaceAll("%times%", 100);
puts(message.String());
This is safe to both integer size and localization issues, and there are no
ugly macros involved. This is what you should use in most Haiku applications.
Since the printf problem is there also for other platforms as soon as you use
fixed-width types, I guess most 3rd-party software is already aware of it. So
this leaves us with printf with non-localized messages, which could still use
BString unless there are good reasons to not do (like the application being
written in C, or running in special cases like KDL where creating an object
might not be a good idea).
--
Adrien.
Other related posts:
