Re: [Libreoffice] Simpler logging using a string format function

On 12/13/2011 07:56 PM, Lubos Lunak wrote:
> On Monday 12 of December 2011, Stephan Bergmann wrote:
> > Shrug.  Neither<<  nor something printf-like is particularly sexy, IMO.
> >    And trading<<  for +, when it requires you to wrap non-string
> > arguments in rtl::OUString::valueOf, doesn't look too exciting to me,
> > either.
>
>   But it might the moment you realize you're trading away things like
>
>   SAL_INFO( "foo", 1<<  2 ) or SAL_INFO( "foo", "bar"<<  "baz" ).

Trading away the former, having to parenthesize (1 << 2) instead, is a 
std C++ trade-off.  Granted, omission of the leading "ostream <<" in the 
macro call makes this somewhat non-obvious.  What is traded away in the 
latter case?

Anyway, bikeshedding about surface syntax is rather pointless.  Some 
seem to prefer a printf-style syntax, while others are fine with a C++ 
<<-based one.

> > - Artificially limited to 9 arguments.  You can sure always extend that,
> > but it's more work than not having to worry about it.
>
>   Hmm. How often is that going to be needed?

With creative uses of SAL_WARN/INFO, I wouldn't be too sure.  ;)  (And 
as I already said, "none of those are critical shortcomings," only 
indicators to me that swapping implementations were not worth it if the 
only benefit were a different syntax.)

> > - No check that there are neither more nor fewer arguments than %Ns (or
> > that the set of %Ns spans a range 1--M without holes).
>
>   There's a todo note, not that I think it matters that much if whoever does
> that runs the code at least once.

Note that at least SAL_WARNs will typically *not* be run by the code 
authors.  (Who goes to the pains of crafting a scenario to make each new 
SAL_WARN actually trigger, by temporarily modifying the code around it 
or creating an appropriate runtime environment?)

>   Well, that's another advantage of the format approach then. It's an
> inconvenience to have to explicitly say the format string is utf-8 (and
> arguments probably as well), but then this conversion can be again limited
> just to logging and not to every std::ostream operation.

Yes, having the message in UTF-16 is an advantage here.  For the 
ostream-based approach, we need to wait for general availability of 
C++11's char16_t.

Stephan