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

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
>>>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.
>  
>
Depending on how the check is performed, the overhead is virtually 
nonexistent.

>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.

Patrick Bennett