On 03/16/2010 01:46 AM, Steven Watanabe wrote:
BOOST_LOG_ATTRIBUTE(logging::trivial::severity_level, severity); BOOST_LOG_ATTRIBUTE(unsigned int, line_id);
I thought if that. It was not done for two reasons:
1. The macro would have to have a formatter in its arguments. Given that the attribute definition should be exposed rather widely, this additional dependency would be unwelcome.
Why is it necessary to pass a formatter to the macro?
In order to support your syntax: fmt::stream << fmt::line_id() << ": <" << fmt::severity() << "> " << fmt::message()
In fact, the semantics are not what I would expect when I just want to pass a parameter, according to http://boost-log.sourceforge.net/libs/log/doc/html/log/rationale/why_weak_sc...
And what would be the expected behavior?
You have extract, attribute_value_extractor, static_type_dispatcher, and dynamic_type_dispatcher. AFAICT, attribute_value_extractor and static_type_dispatcher serve exactly the same purpose. I don't see a good reason to have both as public interfaces.
Not exactly. Type dispatchers, strictly speaking, are not tied to attributes at all. They are used to perform a double dispatch between the attribute value type and the visitor. They may well be used in another area (including, outside Boost.Log).
You're not writing a general purpose dynamic dispatching library, you're writing a logging library. If I wanted such a utility I would certainly not look for it in Boost.Log.
I'm not advertising this tool to be used outside Boost.Log, I just admit that it's not tied with it.