Subject: Re: [boost] [log] Comments
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2010-03-16 11:44:26
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 -
>> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk