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

From: Andreas Wachowski (andreas.wachowski_at_[hidden])
Date: 2005-04-28 13:47:09

Caleb Epstein wrote:
> 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.
> 

Further to the statement above and the other replies to this post by 
Jody and Gennadiy, I would like to add that - in my opinion - categories 
and levels are two *orthogonal* concepts. Although John's approach 
works, it gets laborious soon:

Suppose I have n categories and m levels, then I need n*m logs with the 
current approach, but only n categories + m levels when the two aspects 
are implemented separately.

I have to agree that I would appreciate if levels could be added as a 
distinct feature.

-- Andreas