Re: [boost] [log] Boost.Log formal review ongoing

Subject: Re: [boost] [log] Boost.Log formal review ongoing
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-13 14:14:50

On 03/12/2010 05:05 PM, Darryl Green wrote:
>
> Anyway - I've looked at the docs for boost.log and read some review
> comments to see if we could replace this with the proposed boost.log.
> I've reached the following (possibly wrong) conclusions:
>
> 1) there isn't a direct mapping from this style of logging

Except the filtering based on the message text, I'd say your case is 
covered by Boost.Log rather well. Some things, like having a source per 
severity level, are not required with Boost.Log.

> 2) the obvious approach of making each element of the channel identifier
> an attribute would seem ok - but I'm concerned that the cost of
> evaluating the filters would be significant

The cost will be more significant than comparing a pointer against NULL, 
that's for sure.

> 4) it isn't immediately clear how to support dynamic configuration of
> "filtering" and sinks

Well, the library allows to add/remove sinks, filters and formatters 
during the run time. You can simply call the interface methods as you 
would do it on the library configuration stage.

> 5) attributes seem a little overloaded - the attribute as something to
> be filtered on and the attribute as something to be included in
> (formatted in to) the logged message roles are potentially different. It
> would be nice to have expensive to evaluate attributes that played no
> role in filtering but that were (after filtering "passed" the message)
> evaluated conditionally based on filtering.

It looks to me that it's already implemented, but not exposed to the 
user (since it's only an optimization). If an attribute is not used 
during filtering, and the filter rejects the record, the attribute is 
not evaluated at all.

> 6) There are use cases that boost.log can support (ones where the
> filtering is based on more "dynamic" attributes) that are not practical
> to support in the pure channel based model afaiks. I'd class most of
> these as "alarms" where there is some sort of thresholding or similar
> criteria applied to an attribute value (or combinations) to determine
> whether to log the message.

Hmm, not sure I understand what you mean here. Severity levels, perhaps? 
But you do use them, although they are a part of the channel name in 
your case.