Boost logo

Boost :

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk