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.