Re: [boost] [log] review part 2

Subject: Re: [boost] [log] review part 2
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-16 11:07:55

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_scoped_attributes.html

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.