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

From: Roland J. Weiss (weissr_at_[hidden])
Date: 2005-04-29 05:15:59

Andreas Wachowski wrote:
> 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.

I strongly agree with this statement. I once wrote my own logging lib and
had both categories and levels. It really helped during debugging/monitoring
to be able to focus on different categories at different levels of detail,
just by tuning numbers.

John's lib looks great and has many advanced features, however I miss this
basic functionality.

greetings,
Roland

> 
> -- Andreas
> 
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
> 

-- 
Roland Weiss - Postdoctoral Researcher - Formal Methods Group
WSI-TI, Sand 13, Room 126, University of Tuebingen, 72076 Tuebingen, Germany
Tel: [phone] (07071/29-75940) / Fax: [phone] (07071/29-5062)
E-Mail: roland.weiss_at_[hidden]
WWW: http://www-ti.informatik.uni-tuebingen.de/~weissr