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.