Boost logo

Boost :

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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at