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