[Libreoffice] Simpler logging using a string format function

[Lubos Lunak]

 Hello,

 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.

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

 Now, onto the questions:

1) Yes/no ?
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?
3) What would 'in time for 3.5' mean in practice?
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.
5) For some of the features to work, it is necessary to build without 
gcc's -pedantic. I expect we already would generate some warnings if that was 
used anyway, wouldn't we? BTW, I've tried and built the code with GCC4.5 and 
MSVC 2008.

[1] http://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error
[2] Today's trivia: Did you know that despite being seemingly highly 
optimized, with stuff like OUStringBuffer::makeStringAndClear() or the 
obnoxious RTL_CONSTASCII_USTRINGPARAM macro, O(U)String* actually does some 
rather pathetic things like ctors first checking if there's any memory to 
free or allocated memory being always zeroed first?

-- 
 Lubos Lunak
 l.lunak at suse.cz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a.cxx
Type: text/x-c++src
Size: 14429 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20111212/088bd010/attachment-0001.cxx>