Re: [boost] [log] Yet more questions for Andrey: formatting severity

From: Boris (boriss_at_[hidden])
Date: 2008-08-31 09:16:03

On Sun, 31 Aug 2008 13:58:47 +0200, Andrey Semashev  
<andrey.semashev_at_[hidden]> wrote:

> [...]While I kind of like the idea of wrapping loggers, this particular
> application does not seem valid to me. First, it is formatters that are
> intended to convert attribute values into a sink-specific format. For
> example, we could have both a text sink and a binary sink. The severity
> level is best to be put as a string into the text sink, but as a number
> into the binary sink. Second, in case of decorators, the attribute value

You are right, sounds reasonable to me. As the formatter is a function  
object it should be possible to create a new formatter fmt::severity. It  
would only need to access the attribute Severity and write a string  
instead of the int?

> has to be converted before the call to open_record, which means before
> the filtering takes place. This would lead to a permanent performance
> overhead, even if no logging is done. This is not acceptable.

Let me talk about something different then as I agree that the formatter  
is a good choice for what Igor was asking. :)

The reason why different loggers exist is that each logger tries to update  
a different attribute in open_record()? If I compare for example  
basic_logger and severity_logger the most important difference as far as I  
can tell is:

m_pSeverity->set_value(args[keywords::severity | m_DefaultSeverity]);

The severity attribute is set just before the log record is written in  
severity_logger::open_record(). Now I can create a new attribute and even  
add it to any logger today. However to make a logger update the attribute  
automatically I can't inject a line like the one above. Instead I need to  
create a whole new logger. What I wonder is if the logger can't be made  
more flexible so we don't need to create different loggers just because  
they update different attributes. Even if the decorator pattern doesn't  
fit creating a new logger from scratch only to make a logger update an  
attribute sounds like quite a lot of development overhead?

Boris