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