Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.