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

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2005-04-25 22:50:15

couldn't a macro disable code like:
stream << a << b << c
making operator << a "do nothing" function? I dont think it will have
any overhead in the release code... maybe just for strings "of this
type" that normally isnt optimized away...

On 4/26/05, Patrick Bennett <patrick.bennett_at_[hidden]> wrote:
> 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
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> 

-- 
   Felipe Magno de Almeida
   UIN: 2113442
    email: felipe.almeida at ic unicamp br, felipe.m.almeida at gmail
com, felipe at synergy com
I am a C, modern C++, MFC, ODBC, Windows Services, MAPI developer
from synergy, and Computer Science student from State
University of Campinas(UNICAMP).
To know more about:
Unicamp: http://www.ic.unicamp.br
Synergy: http://www.synergy.com.br
current work: http://www.mintercept.com
"There is no dark side of the moon really. Matter of fact it's all dark."