On 12/13/2011 10:21 PM, Michael Meeks wrote:
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
Again, translation is a non-issue with conceivable uses of this in LO,
right?
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
But that's not related to the code in question. Rather, at the call
site, the printf-style approach amounts to a call to logfunction, while
the <<-style approach amounts to one call to ostringstream ctor and one
or more calls to the appropriate << operators. Granted, the greater
flexibility of the latter results in larger call-site code.
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.
Late in the evening, not late for changes was what I meant.
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 :-)
No need for -DSAL_INTERNAL, I think. The relevant symbols in sal.map
are already in a PRIVATE_1.2 section, so clients that don't use
sal/log.hxx would not be affected by incompatible changes. And if we
think so, we can mark the client-facing functionality in sal/log.hxx as
"for LO internal use only, for now" (we already do so in some other places).
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
