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

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-31 07:58:47

On Sun, 2008-08-31 at 12:56 +0200, Boris wrote:
> On Sun, 31 Aug 2008 11:07:29 +0200, Andrey Semashev  
> <andrey.semashev_at_[hidden]> wrote:
> 
> > Yes, the severity level is stored as an int, and therefore the attr
> > formatter uses operator<< for ints. Right now you can either define your
> > own formatter that will accept an int and transform it into a string, or
> > develop your own attribute and logger to store the level as an enum
> > (then the attr formatter should be used with explicitly specified enum
> > type).
> >
> > I haven't decided yet how to solve this problem best in the library.
> 
> Igor, I'm also interested in your solution (as currently I'm also writing  
> ints to my log files). I would prefer not to define a new logger though.  
> While I like Andrey's logging library a lot I'm not so happy about having  
> different logger types which I need to combine then somehow if I want to  
> use the features of all those logger types (as it is done with  
> severity_channel_logger which combines the severity_logger and the  
> channel_logger; if we add more loggers we get dozens of combinations).

But would you actually need all these combinations? Most likely, you'll
define a couple of loggers with most frequently used features included
and use them throughout the application. Where needed, however, loggers
with more specific features can be defined on a per-case basis.

> I'm not sure either if this approach fits into Andrey's design. According  
> to the definitions at  
> http://boost-log.sourceforge.net/libs/log/doc/html/log/defs.html a logger  
> is a log source (which is a good definition as it is easy to understand).  
> But then it's a bit strange if you need to define a new logger only to  
> customize the output?

Not exactly. Having defined a logger, you customize the level type,
which allows to customize the output later.

> Maybe the decorator pattern could be used here (see  
> http://en.wikipedia.org/wiki/Decorator_pattern for example)? Let's say you  
> want to convert the severity int to a string. You'll define a decorator  
> class and chain the decorator and the logger:

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

I'm leaning towards allowing to customize the level type for the
severity logger, I just haven't figured out how.