On Sun, 31 Aug 2008 13:58:47 +0200, Andrey Semashev <andrey.semashev@gmail.com> 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