[Libreoffice] Simpler logging using a string format function

Lubos Lunak l.lunak at suse.cz
Thu Dec 15 06:58:09 PST 2011


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

 No. I mean that 'foo( "bar" << "baz" )' is incorrect C++, unless foo is a 
macro that does some hidden magic behind the scenes that changes the meaning. 
And not only it's incorrect, it's also not obvious.

 Of course, one can learn this case, and add it to the hundreds of other cases 
that we already have where one either knows it or bumps into it and has to 
start digging around. When was the last time somebody has run e.g. into UNO's 
>>= operator (and that one actually is somewhat more obvious that this)?

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

 I was talking about the strings on the input of the log call. If the syntax 
is SAL_INFO( "area", "File ", file, " not found." ), then "File " and " not 
found." can be converted automatically using utf-8, because it's just a log 
message, so it's very likely only English anyway, and it's a perfectly fine 
way of avoiding the truly horrible SAL_INFO( "area", 
RTL_CONSTASCII_USTRINGPARAM( "File " ), file, RTL_CONSTASCII_USTRINGPARAM( " 
not found." )). At the same time, it does not introduce this automatic 
conversion anywhere else, as the ostream-based operator<< can.

-- 
 Lubos Lunak
 l.lunak at suse.cz


More information about the LibreOffice mailing list