Re: [boost] [log] Comments

Subject: Re: [boost] [log] Comments
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2010-03-16 11:44:26

AMDG

Andrey Semashev wrote:
> On 03/16/2010 01:49 AM, Steven Watanabe wrote:
>> Andrey Semashev wrote:
>>>>> Yes. attr is a formatter and a filter, for example.
>>>>
>>>> Oh, indeed! But.. why? Cannot one object serve both roles?
>>>
>>> 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.

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

>>> 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?

In Christ,
Steven Watanabe