[Libreoffice] Assertions and Logging
Norbert Thiebaud
nthiebaud at gmail.com
Wed Nov 23 09:55:45 PST 2011
>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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>
More information about the LibreOffice
mailing list