Re: [boost] [log] Comments

Subject: Re: [boost] [log] Comments
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-16 12:52:24

On 03/16/2010 06:44 PM, Steven Watanabe wrote:
>
>>>> One is filter and the other is formatter. They have different
>>>> interfaces (with regard to the library and the user)
>>>
>>> Are the interfaces incompatible?
>>
>> Yes. Filters and formatters do different things, how can they share
>> the interface?
>
> I was really asking whether the interfaces conflicted with each other,
> not whether they were different. For that matter, I see no particular
> reason why attr needs to have a different interface when it is used in
> a formatter than when it is used as a filter. In either case, it should be
> a fairly light weight object that stores enough information to extract the
> attribute value from the attribute set. How this value is used can be
> determined from the context.

Technically, it is possible to merge the filter and formatter into a 
single class. However, this looks like a bad design to me, since the 
attr usage syntax becomes ambiguous in different ways, and its 
implementation includes two different and unrelated things.

That approach could probably be reasonable in a general-purpose lambda 
library, but filters and formatters, as they are now, are quite 
specialized (which is not bad).

>>>> and serve different purposes (one - to compose filters, the other -
>>>> formatters).
>>>
>>> Why does this matter? spirit uses the same placeholders in both
>>> qi and karma, for instance.
>>
>> I'm not a specialist in Qi and Karma internals and cannot judge on how
>> that design decision is applicable to Boost.Log. But from my
>> viewpoint, mixing filters and formatters is absolutely not a good idea.
>
> The point is that attr has the same meaning in both
> a filter and a formatter.

Yes, but offers different capabilities. This makes sense for a filter:

   attr< std::string >("Tag").begins_with("Important")

but is completely nonsense as a formatter.

>>>> Also, thread safety requirements are different.
>>>
>>> Why? In any sane implementation that I can think of,
>>> both attr's should store the same immutable data.
>>
>> The formatter attr can contain a boost::format member, which makes it
>> thread-unsafe. Thread unsafe design is common for most formatters.
>
> Is it necessary to have a boost::format object in the
> result of attr?

It's a valuable optimization, since it saves from parsing the format 
string on every log record.