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

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-04-26 11:16:03

On 4/26/05, Jody Hagins <jody-boost-011304_at_[hidden]> wrote:
> On Mon, 25 Apr 2005 14:43:57 +0200
> John Torjo <john.lists_at_[hidden]> wrote:
> 
> > Using the library in code is easy and straightforward:
> >
> > int i = 1, j = 2, k = 3;
> > BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k  <<
> > std::endl; BOOST_LOG(dbg) << "this is a debug message, i=" << i <<
> > std::endl; BOOST_LOG(info) << "I just wanted to tell you
> > something....";
> 
> Along the same lines as other comments, but a little different...
> 
> There should be more than one logging variable.  You said the above
> roughly translates to:
> 
> if ( is_log_enabled(app) ) app_log() << "testing" << i ...;
> 
> However, this restricts the application to one single logging status.  I
> want something like:
> 
> if ( is_log_enabled(logvar_foo, app)
>     app_log(logvar_foo) << "testing" << i ...;
> 
> which allows the application to have many different logging state
> objects.
> 
> In addition, I think any logging statement should be able to be
> conditionally compiled away.  This should also be based on a value.  For
> example, I should be able to specify on the command line something like:
>  compile away all logging statements below level-x, or compile away all
> logging statements for domain foo, below level-x.
> 
> I guess I am looking for more flexibility.  Any logging statement should
> be able to be compiled away.  Any logging statement should be able to
> check multiple levels against one of many different logging state
> objects.

I think John's approach to having multiple log "levels" is to just use
a separate log for each one (e.g. you might have logs called trace,
debug, warning, info, and fatal).  Logs are either enabled or
disabled; there is no "level" or above-some-threshold-type checking as
with some other common implementations.

As far as conditional compilation goes, I think John has agreed to add
a new macro that would enclose an entire logging call and could be
compiled out of production code.

-- 
Caleb Epstein
caleb dot epstein at gmail dot com