From: Bennett, Patrick (Patrick.Bennett_at_[hidden])
Date: 2005-04-26 10:44:00
> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Darren Cook
> Sent: Tuesday, April 26, 2005 1:06 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Logging Library -- Formal Review Request
>
> > Depending on how the check is performed, the overhead is virtually
> > nonexistent.
>
> But still there :-).
[Bennett, Patrick] If you're concerned about a simple lookup, compare,
and jump, sure. :)
> >> 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 -
>
> It is also slightly shorter. It seems just as natural to me.
[Bennett, Patrick] I suppose everybody has their preferences. I'm not
one to discount that. :)
...
> But I want to have both: I want some log statements I can insert while
> debugging time-critical code and disable at compile time, and others
> that are always there but that I can choose to switch on and off at
> run-time. And I want both in the same project.
>
> Perhaps then BOOST_LOG_DBG() is a better name for the one that can be
> compiled out. Or BOOST_LOGD().
[Bennett, Patrick] Sounds fine. I guess I just see the requirements
quite a bit different than (probably) many. I see a logging/tracing
library as something for diagnostics and debugging, not as a
here-and-there std::cout<<xxx substitute.
Many of the applications at the company I work at can easily log
*gigabytes* of diagnostic data an hour per subsystem. Logging isn't an
occasional nice to have for us, it's an absolutely necessity.
Patrick Bennett