[Libreoffice] Simpler logging using a string format function

[Michael Meeks]

On Mon, 2011-12-12 at 22:59 +0100, Stephan Bergmann wrote:
> To be honest, I don't think the stated benefits (a different syntax) are 
> worth a switch.

	Well; the syntax that makes translation possible is a nice thing; but
to me - having something efficient - that does not turn into some huge
sequence of calls is what I'm interested in. We have quite enough bloat
size-wise as it is, and infrastructure that makes it easy to create
small, efficient code is much to be praised I feel.

	rtl::OUString x = "a" + 4 + "c";
turns into:
        x = new OUStringBuffer().append("a").append(4).append("c")
                              .makeStringAndClear()

	Which looks (to me) like a lot of back-to-back calls (in place of one);
and presumably some chunk of exception unwind table too. [ speaking of
which, we should consult Jan or some suitable gcc expert on whether:

#define SAL_THROW_EXTERN_C() throw ()

	might be better as __attribute__((nothrow)) - which may avoid some
'unexpected' misfeature in this area. Similarly, it might be rather nice
from a performance perspective to have some SAL_CONST and SAL_PURE
function annotations (or similar) so we can annotate eg. all those
getCppuType style .hpp methods as const; particularly since even LTO
would find that hard.

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

	Sure.

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

	Presumably checking that as the arguments are substituted is
reasonable; if someone wants to pass an extra argument it's hardly going
to be worse than inlining lots of back-to-back ustring calls -
right ? :-)

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

	Heh.

	Wrt. the panicing about now-or-never-again changes to these SAL_INFO
style macros, that seems a bit over-done to me.

	If there is any uncertainty about what we want to do with SAL_INFO and
friends, I suggest we just add a -DSAL_INTERNAL parameter (or alike) to
our build environment, and have some pieces of sal which are only for
internal use. Then we can improve this at our leisure without panicing
about sal's precious ABI :-)

	I tend to think that's the best approach here really; we flatter
ourselves to think that there are many external users of sal/ so I think
we should really make our lives as easy and flexible as possible for
internal use.

	ATB,

		Michael

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