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

On Monday 12 of December 2011, Michael Meeks wrote:
> On Mon, 2011-12-12 at 16:30 +0100, Lubos Lunak wrote:
> >  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 :-)

 Note that as shown in the 'message construction bloat' thread this can easily 
be

 o_rEmbeddedURL = "vnd.sun.star.Package:" + media + '/' + filename;

 and be as efficient as possible. As soon as SUSE has the next HackWeek :).

 Stephan's reply made me realize it would be better to have the format 
functionality specialized for logging, so that there can be easy conversions 
even for types like SwNode where one definitely does not want a conversion to 
a string in any other case. There could be a separate functionality for 
strings as well, but I can't quite judge the usefulness for LO - Qt has this 
and it's used in KDE a lot, but it's mostly for creating UI strings ("Open 
file %1 in %2?" is certainly better for both coders and translators) and LO 
has a different system for translations.

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

 That depends exactly on the requirements. If one wants a small single call in 
the place of use, then all those templates have to be generated somewhere, 
and although the most used ones can be made external, the number of possible 
combinations explodes here. The other extreme would be inlining everything 
but then the place of the call would generate larger code. And if this is to 
end up in an ABI stable library then there's not much room for later 
experiments :-/.

-- 
 Lubos Lunak
 l.lunak@suse.cz