[Libreoffice] message construction bloat ...

[Stephan Bergmann]

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