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


While a central registry of such defines could be useful also for consistency and to avoid typos, 
it is the very "central registry" aspect that makes it look unattractive to me.

Sure, but at least the technic I mentionned would allow for us to
_choose_ one way or another
If you stick with string as the area argument, the barrier to change
to a central repository will be so high as to insure that it will
indeed never happen.



 For production builds, my assumption is they would
routinely log either nothing at all or *all* SAL_WARNs.  So only if a user
would explicitly enable certain area-restricted SAL_INFOs (to find out more
about a reproducible problem he experiences) would the decision to represent
areas as strings necessarily have negative consequences (which IMO would
again be tolerable in that special scenario).

This is a self fulling prophecy. beside in order to exclude them all
you still need to parse your env variable no?
so sure the parsing will be (relatively) fast... but you still get a
couple of prologue, epilogue, a couple of variable initialization, a
get_env
so a no-op operation is still 100x more instructions than necessary.

actually reading the code if env = NULL you force it to +WARN and then
go ahead an parse it...:-(


Note that this discussion is orthogonal to whether to use fprintf or
something more c++ friendly. I don;t care too much about that since
once the decision is made to actually do the trace I don't care as
much about performance... it is going to be slow either way...
What I care about is that we can use that facility quite liberaly with
the knowledge that as long as you are not actually taking the trace
the cost is minimal.

To that extend, pushing as much or the complexity to the init function
and make the wrapper that trigger the trace as lightweight as possible
is desirable.

Note that I'm arguing from a position where I'd like to have such
facility cheap and usable in release build.. this is above and beyond
what we currently have.

Norbert





_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


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.