From: Patrick Bennett (patrick.bennett_at_[hidden])
Date: 2005-04-25 22:15:42
Darren Cook wrote:
>>>Hi. If I understand right the code, even if log is disabled, I do pay
>>>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.
Depending on how the check is performed, the overhead is virtually
>I think it is very important that we can choose to build with all
>logging code removed. This has been discussed before, and I thought you
>were going to include an alternative macro, something like:
> BOOST_LOG(app,"testing " << i << '-' << j << '-' << k);
Well, you can count my vote against this method.
For you, the entire point of doing it this way is so that the logging
can be compiled out - which, at least in my view, is a huge mistake. I
have my opinions about the 'style' of this type of logging as well
(where the entire streamed message is simply an 'argument' to a
fictitious 'method') - as opposed to the proposed method which is
certainly much more natural (in a stream << xxxx way).
Having worked on quite a few large-scale commercial software products
using an extensive logging framework for quite a few years now, I can
attest that, short of embedded deployment, there is almost never a
reason to compile out tracing code.
It's far, far too important for debugging customer problems (where you
can't just launch the debugger and snoop around). All you frequently
have to diagnose a problem in the field are the log files. Logging
isn't a nice to have, it's an absolute requirement.
>(Would that compile? If so I think this should be the main macro, and
>the above format the alternative.)
I at least, strongly disagree - but you already knew that. :)
I think the logging methods should be designed for the majority of the
users. If the majority of the users believe they should always have
diagnostic logging methods available to be turned on at any time during
runtime, then the 'if (test) ; else stream' macro should be the
'standard' way of doing things. If the majority of users want the
logging to just be there occasionally and see it only as a 'printf'
alternative in debug builds as opposed to a diagnostic tool available at
the flick of a switch, then by all means, the sometimes there, sometimes
not, wrap it all in a single macro argument style should win out.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk