Re: [boost] [log] Comments

Subject: Re: [boost] [log] Comments
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-16 14:05:59

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.