[Libreoffice] Simpler logging using a string format function

[Lubos Lunak]

On Thursday 15 of December 2011, Stephan Bergmann wrote:
> On 12/13/2011 07:56 PM, Lubos Lunak wrote:
> >   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?

 The "bar" << "baz", which, at first glance, is nonsense. Code is not only 
written, it is also read, and many more times.

> Anyway, bikeshedding about surface syntax is rather pointless.

 Well, I did say that longer exposure to this codebase makes people oblivious 
to bad API, didn't I? This is not bikesheding. This is adding yet one more 
case of ugly API to the codebase, and while it's not tragically fugly and 
neither are most of the other, it simply all adds up and the result is a 
fugly codebase where even adding two strings together is an exercise. And it 
will not get better if such stuff will keep getting added because surface 
syntax, the thing developers deal with most of the time, is supposedly rather 
pointless.

> >> - 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.)

 It's not a big deal to add letters too for creative uses and 37 arguments to 
a log call is as implausible to be next to unrealistic.

> >> - 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?)

 Hmm, right. Ok, forget the format. I can make it

 SAL_INFO( "foo", "string ", s, " of length ", n )

 and that solves most of your objections I believe, while still keeping most 
of the advantages compared to the ostream approach.

> >   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.

 They are log messages. They are written in English.

-- 
 Lubos Lunak
 l.lunak at suse.cz