From: Gareth Buxton (gareth.buxton_at_[hidden])
Date: 2007-04-08 17:30:34
Andrey Semashev wrote:
> 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
So you could define a type:
class line_number : public maskable
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk