On 11/23/2011 01:59 PM, Michael Meeks wrote:
Given that the real per-site difference is larger. Add to this the
issue that there are real translation problems with the 2nd approach
(that it cannot be appropriately re-ordered), and IMHO the argument here
is overwhelmingly against 'cute' operator-overloading approaches - where
each 'little' operator turns into a chunky function call at compile
time. Clearly if we introduce operators / allocations that can throw -
we also end up with some chunky eh_frame / exception unwind tables too.
Translatability should be a non-issue here, no? (Given the way we
localize the LO UI.)
If we can choose a way of constructing message, IMHO it should not be
one that has this problem; concatenation by '+' operator shares this of
course.
"This problem" being code size or translatability?
I know C++ doesn't like var-args, and I know var-args is type-unsafe,
and thus per-se 'evil' :-) but it also happens to be really easy to use
& read, better to translate, very familiar to most developers, and ...
Not sure whether
"Value is %" SAL_PRIdINT32, n
compared to
"Value is " << n
is really more "easy to use & read" and "very familiar to most
developers." ;) Another problem with printf is that it requires less
natural ways to get OUStrings into the output (either we implement the
format scanner ourselves, supporting %S; or you need to decorate
call-sites with some sort of to-char* conversion).
But sure, the drawback of stream-style is the increased call-site code size.
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
