The logging macros

[Mattias Brändström <th...@brasse.org>]

Hello!

I was looking at the logging macros in log4cxx and I have one question. 
Is there any particular reason why the macros aren't enclosed in an #if 
like this:

#if !defined(LOG4CXX_DISABLE_DEBUG)

macro definition here

#endif

I suspect that there is a reason for this, I just can't figure it out on 
my own. :-) So please enlighten me.

:.:: mattias

Re: The logging macros

[drkm <da...@yahoo.fr>]

FabijanicA@nucorsteel.com writes:

> If you are not willing to pay it at production runtime, you have a
> choices of wrapping your calls into #ifdefs or redefining LOG_DEBUG
> into nothing and have compile time control.

  Or best, IMHO, define your own macro like this :

    #if defined( NDEBUG )
    #  define MY_DISABLED_IN_REALASE_LOGGING_DEBUG( logger , msg )
    #else
    #  define MY_DISABLED_IN_REALASE_LOGGING_DEBUG( logger , msg ) \
           LOG4CXX_DEBUG( logger , msg )
    #endif

--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html

Re: The logging macros

[Fa...@nucorsteel.com]

Mattias Brändström <th...@brasse.org> wrote on 08/26/2004 09:10:04 AM:

> The reason I was asking about the macros was that I am a little 
> concerned about the performance impact of making the logging calls all 
> the time. I sometimes want to sprinkle my code with debug messages and 
> leave them there. If I can recompile with LOG_DEBUG types macros 
> disabled I won't have to worry about those debug messages stealing 
> resources from the rest of the application. Should I worry about this if 

> I am using log4cxx?

Again, all I can tell you is that all your performance penalty is in the 
following line:

if (logger->isEnabledFor(level))

If you are not willing to pay it at production runtime, you have a choices 
of wrapping your calls into #ifdefs or redefining LOG_DEBUG into nothing 
and have compile time control.

I am not aware of built-in compile time control mechanism with log4cxx.

Alex

Re: The logging macros

[Mattias Brändström <th...@brasse.org>]

Hello!

(For some reason I have messed up my inbox. This messages is intended to 
be a reply to Alex message)

The reason I was asking about the macros was that I am a little 
concerned about the performance impact of making the logging calls all 
the time. I sometimes want to sprinkle my code with debug messages and 
leave them there. If I can recompile with LOG_DEBUG types macros 
disabled I won't have to worry about those debug messages stealing 
resources from the rest of the application. Should I worry about this if 
I am using log4cxx?

:.:: mattias

Mattias Brändström wrote:
> Hello!
> 
> I was looking at the logging macros in log4cxx and I have one question. 
> Is there any particular reason why the macros aren't enclosed in an #if 
> like this:
> 
> #if !defined(LOG4CXX_DISABLE_DEBUG)
> 
> macro definition here
> 
> #endif
> 
> I suspect that there is a reason for this, I just can't figure it out on 
> my own. :-) So please enlighten me.
> 
> :.:: mattias

Re: The logging macros

[Fa...@nucorsteel.com]

I suspect you are thinking in an "old fashion" way where log levels are 
determined by #defines at preprocessing time. Log4cxx does this based on 
configuration file settings. 
If you look at the logging macros you'll see: 

if (logger->isEnabledFor(level)) { 
... 
} 

This way, the desired log level is set at runtime without a need for 
recompiling (or even having access to) the source code. Of course, there 
is a small performance price to pay. 

Alex 

Mattias Brändström <th...@brasse.org> wrote on 08/20/2004 04:37:47 AM:

> Hello!
> 
> I was looking at the logging macros in log4cxx and I have one question. 
> Is there any particular reason why the macros aren't enclosed in an #if 
> like this:
> 
> #if !defined(LOG4CXX_DISABLE_DEBUG)
> 
> macro definition here
> 
> #endif
> 
> I suspect that there is a reason for this, I just can't figure it out on 

> my own. :-) So please enlighten me.
> 
> :.:: mattias