Re: [boost] Re: recommend logging library?

From: Mark Blewett (boost_at_[hidden])
Date: 2004-03-18 18:55:50

At 23:03 18/03/2004, you wrote:

>Rob Stewart wrote:
>>From: "Neal D. Becker" <ndbecker2_at_[hidden]>
>>
>>>John Torjo wrote:
>>>
>>>>Neal D. Becker wrote:
>>>>
>>>>
>>>>>I notice boost doesn't have a logging library.  I have seen several
>>>>>floating
>>>>>around.  Are there any recommendations?
>>>>
>>>>How about std::ostream ;) ?
>>>>
>>>>Also, disabling writing to a stream is fairly easy, by setting the
>>>>failbit of a stream object:
>>>>out.setstate( std::ios::failbit); // nothing gets written to this log
>>>>any more
>>>
>>>Interesting idea.  I would like the overhead of disabled loggers to be
>>>relatively small.  Would you think this technique might be useful in that
>>>case?  (Of course, relatively small is a relative term).
>>
>>Every insertion and every mf you call on the stream must occur
>>and must check the failbit flag.  It would, therefore, have
>>noticeable overhead.  Is it a problem?  Maybe.  You could time an
>>app with the logging compiled away (via preprocessor) and with
>>the failbit set.
>
>I think it's the wrong approach. In our company we have implemented 
>logging through macros which has one very important property: When I write
>
>LOG_DEBUG( whatever() );
>
>into my source, then whatever() is only evaluated when the debug-logger is 
>active. The macro basically expands to something like this:
>
>if( Base::hasLogger( LogLevel::DEBUG ) )
>   Base::log( whatever(), LogLevel::DEBUG );
>
>I think this cannot be done without macros as normal function calls 
>(including operator<< for streams) need to evaluate their arguments before 
>they are called. As the difference in the application execution speed can 
>vary by a factor of 1000, this is a very valuable optimization for us. My 2¢.

Personally I think restricting boost to disabling logging on a #define is a 
double negative... ie a no no.

It would be fine if boost was just used in developing "packaged" software, 
but in the real world where customers buy a big product *and* support, its 
very useful to be able to turn debugging on/off at runtime with the 
delivered solution.

Having said that the previous post I think that's on the right lines, tho 
in the code we use don't hide behind a macro, for example my preferred syntax

if (debug_trace.enabled())
{
         report(debug_trace, .... ) << "Somethings gone wrong x=" << x;
}

Very simple to use... you just have to instill into the team that reports 
stream operators cost, and you better check if the trace is enabled :o)

I guess you could get the best of both worlds and wrap it up in a macro

#define BOOST_LOG(Trace, ...., Message) \
         if (Trace.enabled()) { report(Trace, .... ) << Message; }

which is kind of getting to something similar to the previous post.

Regards
Mark 


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.614 / Virus Database: 393 - Release Date: 05/03/2004