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
>>> 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
>>> 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
>> 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
> -- Andreas
> Unsubscribe & other changes:
-- Roland Weiss - Postdoctoral Researcher - Formal Methods Group WSI-TI, Sand 13, Room 126, University of Tuebingen, 72076 Tuebingen, Germany Tel: +49 7071 2975940 (07071/29-75940) / Fax: +49 7071 29-5062 (07071/29-5062) E-Mail: roland.weiss_at_[hidden] WWW: http://www-ti.informatik.uni-tuebingen.de/~weissr
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk