On 03/16/2010 08:35 PM, Steven Watanabe wrote:
AMDG
Andrey Semashev wrote:
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.
How is it ambiguous? I don't like having to refer to the same thing by different names depending on how I'm going to use it. You should be able to determine how to treat the attr from the context that it's used in.
attr< int >("X", "%04x") > 10 Is that a formatter or a filter? If attr was a lambda placeholder, as you suggest, this expression would probably compile, until being assigned to a variable or being invoked either way. Also, if attr was polymorphic, would this compile: function< bool (attribute_values_view const&) > f = attr< int >("X"); ? That shouldn't compile, assuming that attr< int >("X") is a formatter (because the signature differs) or a filter (because that filter is incomplete).
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).
This specialization is bad if it forces you to have separate attrs.
From their implementation standpoint, they have nearly nothing in common.
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.
Then I won't use this expression as a formatter. Anyway, if you want to avoid coupling specific tests to the attr, non-members are your friends.
You mean, like this: bind(begins_with, bind(attr< std::string >("Tag"), _1)), "Important") ? Compared to my syntax, this looks cryptic, to say the least.
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.
Have you measured the effect? Oh, I see what you mean. I would have no problem if you dropped the format parameter of attr entirely.
But I don't want to drop it. It's quite useful.