Boost logo

Boost :

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
>>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.

-- Andreas

Boost list run by bdawes at, gregod at, cpdaniel at, john at