Re: [boost] A meta-proposal for logging

From: Gareth Buxton (gareth.buxton_at_[hidden])
Date: 2007-04-09 05:13:15

Hi Andrey,
> You see, in your example the filter would get "maskable& line", not
> "line_number& line" as the logging library doesn't know about
> "line_number" class. This means that you will have to make some type
> dispatch to get the real attribute type, and I'm afraid this will be
> a performance killer.
>
>   
It could be but I don't think it necessarily has to. My solution would 
be to tightly couple the filter with the attributes that are to be 
filtered on the basis that if the user is adding the attributes then the 
use knows how best to filter based on them.

It seems logical to me that if some one is writing a filter based upon a 
specific attribute then they must know the attributes type to a certain 
degree.

> Other two problems here are:
> 1. I believe the "to_string" member function you mentioned (I guess,
> you meant to use it to format sinks' output) should not be a part of
> attribute. I should be a sink's implementation detail (and in fact, it
> may be customizable). For example, a date that is initially
> represented as time_t, may be differently formatted as string by text
> sinks and may be dumped into file as int by binary sinks.
>   
Yes. Your example of time is a good one. I think you are absolutely 
right here that it is the formatting object that should decide how to 
represent the attribute. This implies (like with the filter) that the 
user who produced the formatting object will understand enough about the 
attribute's type to make this feasible.
> 2. I would like filters to be as much independent from attributes
> as possible. IMO, in real applications the filters will be generated
> in very different places (and maybe modules) than the attributes and
> often they will not even know real attribute's type. In your example,
> imagine the "my_filt" doesn't know that "line_number" exists.
>
>   
I think it is inevitable that *some* attribute type information be known 
by both filter producers and formatters. I just can not see a way around 
this whilst at the same time allowing user defined attribute types. I 
don't think this would necessarily be burdensome. It  means that 
attributes  will have to be documented.

In your example if 'my_filt' does not know that 'line_number' exists 
then it will not be able to filter based upon that attribute and there 
is no cure for that.  However anyone creating a filter that would log 
only a certain range of line numbers (for example) will know of and be 
expecting the 'line_number' attribute to be present.

Of course if the expected attribute is missing the filter should not break.

I tend to think that some amount of coupling is inevitable, for the most 
part I would imagine attributes would be well known, frequently used 
types like time (time_t), line_number (int) etc. and would be provided 
as 'standard' in the library.