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

Hi Lubos,

On Mon, 2011-12-12 at 16:30 +0100, 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 )

        Oooh - nice ;-)

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

        I'd love that personally; I'd love to have it as a way to construct
OUStrings as well - potentially rather more readable and more
efficient/faster than an OUStringBuffer for those cases where we can
calculate a precise allocation size from our arguments first. There are
a lot of call sites like:

avmedia/source/framework/mediaitem.cxx:
        ::rtl::OUStringBuffer buf(::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(
                        "vnd.sun.star.Package:")));
        buf.append(media);
        buf.append(sal_Unicode('/'));
        buf.append(filename);
        o_rEmbeddedURL = buf.makeStringAndClear();

        That are crying out to be one-liners with this sort of thing :-) in
fact, large numbers of rtl::OUStringBuffer usage sites could be made
more succinct, readable, maintainable and potentially more efficient
with this :-)

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

        We can (presumably) inline them - they all evaporate away. It seems
that it does indeed turn into a single function call. I imagine we
should put the virtual 'append' methods into a separate shared object
though.

> 1) Yes/no ?

        I love it; Stephan ?

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

        I suppose so :-)

> 3) What would 'in time for 3.5' mean in practice?

        Tripple review at this stage - but, I think that's reasonably
achievable; you got one already.

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

        ;-) seems more than likely. So - lovely work; I rather like the
solution (at least from an assembler perspective, from what I saw so
far). Incidentally, to compile:

g++ -S -DLINUX -DUNX -I/path/to/core/solver/unxlngi6.pro/inc/ /tmp/a.cxx

        etc. I'll push it onto the TSC agenda in case we don't get consensus here.

        ATB,

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot