RE: [boost] Logging Library -- Formal Review Request

From: Terence Wilson (tez_at_[hidden])
Date: 2005-05-08 12:11:57

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Darren Cook
> Sent: Monday, April 25, 2005 7:03 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Logging Library -- Formal Review Request
> 
> >> Hi. If I understand right the code, even if log is 
> disabled, I do pay 
> >> for constructing log messages. Am I right? If so why do you force 
> >> this?
> >
> > No, you donot pay.
> > 
> > BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k;
> > 
> > Is the equivalent of:
> > 
> > if ( is_log_enabled(app) ) app_log() << "testing" << i ...;
> 
> But it is still taking up space; not to mention CPU usage 
> doing a run-time check to see if a log is enabled.
> 

I'm a little late to the game but FWIW I agree with Darren, in our
application we would like to log our bottleneck code, we cannot afford to
pay for functions we don't use. In my own logging library I solved the
problem by having both dynamic and static logging. In the static version the
logging flags are defined and tested at compile time, if a particular
logging statement is not activated based on the log flags it is completely
eliminated. For dynamic logging the test is left because the log flags can
be changed at runtime. The type of logging is selected by a macro.

One approach to logging is to build two binaries for each release, the first
has all logging turned off, this is the version that is installed on the
customer's machine. The second has dynamic logging present, so that when we
need to get a log report we can have the user run the second binary as a
drop in replacement, with the appropriate flags passed as a parameter. It's
not a perfect solution but it's the closest you can get to the best of both
worlds- performance and good diagnostic information.