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.