[Libreoffice] Simpler logging using a string format function
Stephan Bergmann
sbergman at redhat.com
Thu Dec 15 01:04:22 PST 2011
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
More information about the LibreOffice
mailing list