[Libreoffice] Simpler logging using a string format function

[Stephan Bergmann]

On 12/13/2011 10:21 PM, Michael Meeks wrote:
>
> On Mon, 2011-12-12 at 22:59 +0100, Stephan Bergmann wrote:
>> To be honest, I don't think the stated benefits (a different syntax) are
>> worth a switch.
>
> 	Well; the syntax that makes translation possible is a nice thing; but

Again, translation is a non-issue with conceivable uses of this in LO, 
right?

> to me - having something efficient - that does not turn into some huge
> sequence of calls is what I'm interested in. We have quite enough bloat
> size-wise as it is, and infrastructure that makes it easy to create
> small, efficient code is much to be praised I feel.
>
> 	rtl::OUString x = "a" + 4 + "c";
> turns into:
>          x = new OUStringBuffer().append("a").append(4).append("c")
>                                .makeStringAndClear()
>
> 	Which looks (to me) like a lot of back-to-back calls (in place of one);
> and presumably some chunk of exception unwind table too. [ speaking of

But that's not related to the code in question.  Rather, at the call 
site, the printf-style approach amounts to a call to logfunction, while 
the <<-style approach amounts to one call to ostringstream ctor and one 
or more calls to the appropriate << operators.  Granted, the greater 
flexibility of the latter results in larger call-site code.

>> Sure, none of those are critical shortcomings, though.  (And its late
>> already, and maybe I'm just missing an obvious benefit completely.)
>
> 	Heh.
>
> 	Wrt. the panicing about now-or-never-again changes to these SAL_INFO
> style macros, that seems a bit over-done to me.

Late in the evening, not late for changes was what I meant.

> 	If there is any uncertainty about what we want to do with SAL_INFO and
> friends, I suggest we just add a -DSAL_INTERNAL parameter (or alike) to
> our build environment, and have some pieces of sal which are only for
> internal use. Then we can improve this at our leisure without panicing
> about sal's precious ABI :-)

No need for -DSAL_INTERNAL, I think.  The relevant symbols in sal.map 
are already in a PRIVATE_1.2 section, so clients that don't use 
sal/log.hxx would not be affected by incompatible changes.  And if we 
think so, we can mark the client-facing functionality in sal/log.hxx as 
"for LO internal use only, for now" (we already do so in some other places).

Stephan