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.me...@suse.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
