[Libreoffice] Simpler logging using a string format function

[Stephan Bergmann]

On 12/15/2011 02:57 PM, Lubos Lunak wrote:
> 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.

Still don't get what you mean.  You mean, "bar" << "baz" should be 
forbidden by the compiler, making sure one writes "barbaz" instead?

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

I still think neither approach is more beautiful than the other.  But 
that's subjective, of course.

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

Erm, are we talking past each other here?  The fully composed log 
message, with string arguments placed into it, somehow needs to handle 
the UTF-16 string arguments placed into it.  All I wanted to say is that 
your approach, building up the fully composed message as 
rtl::OUStringBuffer, shields client code from having to specify how to 
translate any rtl::OUString arguments into the proper format.

Stephan