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

From: Boris (boriss_at_[hidden])
Date: 2008-08-31 06:56:05

On Sun, 31 Aug 2008 11:07:29 +0200, Andrey Semashev  
<andrey.semashev_at_[hidden]> wrote:

> On Sat, 2008-08-30 at 23:16 -0700, Igor Nazarenko wrote:
>> By default, severity is printed as integer. What's the easiest way to
>> print the corresponding string (e.g. "info" for severity 0, "warn" for
>> severity 1, and so on)?
>>
>> I tried defining operator<< for my severity enum, but
>> attr<severity_level> doesn't work; that is, the output operator
>> doesn't get invoked (I assume because attribute "Severity" is
>> internally of type "int" and not of my enum type).
>
> 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).

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?

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:

logger log;
my_decorator deco(log);
BOOST_LOG(deco) << "Test";

The decorator behaves like the logger (same interface). It processes some  
attributes in open_record (like converting the enumeration to a string)  
before it forwards the call to logger::open_record. That would make it  
possible to process attributes without introducing new classes like  
my_decorator_logger, my_decorator_severity_logger,  
my_decorator_channel_logger, my_decorator_severity_channel_logger etc.  
depending on what features you need. Of course you could also combine  
decorators with:

logger log;
my_decorator1 deco1(log);
my_decorator2 deco2(deco1);
BOOST_LOG(deco2) << "Test";

Boris