>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 > _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
