Re: [boost] [log] Comments

Subject: Re: [boost] [log] Comments
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2010-03-16 13:35:28

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.

> 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.

>> 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.

>>> 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.

In Christ,
Steven Watanabe