-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Darren Cook Sent: Monday, April 25, 2005 7:03 PM To: boost@lists.boost.org 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.