Re: [Libreoffice] Simpler logging using a string format function

On 12/12/2011 04:30 PM, Lubos Lunak wrote:
>   I'd like to propose changes to the SAL_INFO etc. family of the new logging
> functions that would replace the somewhat strange usage
>
> SAL_INFO("foo", "string "<<  s<<  " of length "<<  n)
>
>   with
>
> SAL_INFO("foo", "string %1 of length %2", s, n )
>
>   while still leaving the possibility to do
>
> SAL_INFO("foo", "string " + s + " of length "  + OUString::valueOf( n ))
>
>   The last two are IMO much more natural than the iostream-based usage.

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.

>   The format-based usage uses a printf-like function that, unlike printf, is
> typesafe and extensible. If people would be interested, the function itself
> could be made public API (after all, there's a reason why printf is still
> popular even nowadays, despite all its shortcomings).
>
>   Attached source code has a testing implementation of the format function and
> a simple logging macro. It still needs few final touches but it's generally
> ready. The templates may look scary at first, but it's rather simple, they
> are just making the function to take up to 9 arguments of each of the
> supported arguments and the template for return type is SFINAE[1]. I also had
> a look at the resulting code and it's usually pretty small (can be tweaked by
> where the inline keyword is put, this way the call at the place of usage is
> very small) and reasonably fast (could be done even faster if OUString being
> actually rather lame didn't make it somewhat pointless[2]).

To be honest, I don't think the stated benefits (a different syntax) are 
worth a switch.  The drawbacks I see with this roll-your-own approach, 
compared to building on std::ostream functionality, are:

- Artificially limited to 9 arguments.  You can sure always extend that, 
but it's more work than not having to worry about it.

- Limited to types for which there is a FORMATTER_APPEND_BASED call.  At 
least theoretically, a C++ implementation can e.g., have additional 
numerical types (and use them as, say, std::vector<T>::size_type) for 
which it transparently offers std::ostream inserters.  Again, this can 
always be extended, but it needs to be done.

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

Sure, none of those are critical shortcomings, though.  (And its late 
already, and maybe I'm just missing an obvious benefit completely.)

> 2) It take it SAL_INFO, being in sal, has to keep binary compatibility, which
> means we're stuck with the<<  usage if it stays that way in the 3.5 branch,
> and that I'd have to make this new way binary compatible in time for 3.5 if
> it's to replace it?

Yes.

> 4) What is the LO policy on char*<->  OUString conversions? It seems to me
> they always need to be explicit, but I'd prefer to ask.

Yes, always as explicit as suitable, please.  Especially since you 
generally need to specify the text encoding of the char* data, anyway. 
(The current, std::ostream inserter based stuff violates this somewhat, 
offering an inserter for rtl::OUString that implicitly uses 
RTL_TEXTENCODING_UTF8, upon explicit #include 
"rtl/oustringostreaminserter.hxx".)

Stephan