Re: [boost] A meta-proposal for logging

From: Gareth Buxton (gareth.buxton_at_[hidden])
Date: 2007-04-08 17:30:34

Andrey Semashev wrote:
> Hello,
>
> I have a question about the logging attributes concept.
>
> I'm thinking now about the implementation of attributes, filtering and
> sinks (in particular, formatting log messages in sinks) and I come to
> a conclusion that we have to mandate the set of types that will be
> used in the attributes<->logging library interface. The reason we have
> to do this is that the library should be able to be compiled
> separately from the user's code (i.e., in dll), which defines the
> attributes. It doesn't mean, though, that the user won't be able to
> define arbitrary types of attributes, but these types should be
> representable in one of a predefined set of types.
>
> For now I see the following types set being suitable for this purpose:
> - int
> - unsigned int
> - long long
> - unsigned long long
> - double
> - std::string or std::wstring, depending on the library configuration
> - boost::any. This won't be supported by the library's sinks out of
> box and is aimed for extensibility on the users' behalf.
>
> I know such lack of generalization is not welcome, but I can't figure
> out any other way to organize interaction between different dlls.
> Maybe there are other opinions?
>
>   
I've been scratching my head about this. I'm currently trying a 
mechanism where you define a type (maskable) and all attributes need to 
be derived from that type. This way the filter can then apply a member 
from the maskable interface to determine if the message can succeed with 
this particular attribute.... Also there would be a member to convert 
to_string.

So you could define a type:

class line_number : public maskable
{
    int l;
 ...
};

then  define your filter

class my_filt : public filter
{
     bool pass(line_number& line)
    {
        return line.l > my_threshold;
    }
};

This would necessitate a constraint (every type you use for an attribute 
must derive from maskable) but then that's part of the framework that I 
cant see how to avoid.