Re: [boost] [log] review part 2

Subject: Re: [boost] [log] review part 2
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2010-03-24 14:35:31

AMDG

Andrey Semashev wrote:
> On 03/24/2010 01:25 PM, Vladimir Prus wrote:
>> On Tuesday 16 March 2010 18:07:55 Andrey Semashev wrote:
>>> 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()
>
> Well, my assertion stays valid - the macro would expose formatters to 
> all code that uses the attribute, and that is not desirable 
> (especially in light of the expressed concerns about compilation times).
>
> There was further discussion on porting filters and formatters to 
> Boost.Proto. I can't tell if this would alleviate the problem, but if 
> it appears that it is possible not to introduce that dependency or the 
> dependency is ultra-light, then I will provide something like that.

Proto isn't needed.

If attr returns a struct like

template<class Types>
struct attr_t {
    const char* name;
};

Then the extra code needed to treat it as a formatter
can be added by operator<< and operator%.  These
operators don't need to be defined in the same header

In Christ,
Steven Watanabe