$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [log] Comments
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-16 15:19:02
On 03/16/2010 09:44 PM, Steven Watanabe wrote:
> AMDG
>
>>> This specialization is bad if it forces you to have separate attrs.
>>
>> From their implementation standpoint, they have nearly nothing in common.
>
> Then all the sophisticated implementation doesn't belong in attr.
> It belongs in the whole formatter/filter object.
>
>> 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.
>
> No I meant, begins_with(attr<std::string>("Tag"), "Important").
> I don't understand why you think that random extra stuff
> is needed just because a member function is turned into
> a non-member. FWIW, the bind syntax would mostly work as is with
> no extra work from you, if attr just returned a function object,
> so I don't think it's necessarily a bad thing, since I really do not
> like to see you reinventing the wheel in so many places.
I understand where you're leading - to rewrite filters and formatters in
terms of Proto or Phoenix. I admit that you made a few very good points,
and I'm not against this move. But I'm not ready to drop my syntax
advantages in the process. Ideally, I would prefer that the current
syntax was possible without changes in the rewritten code. In order to
complete this task I'll need time to study these libraries closer.
>>> 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.
>
> You can already use Boost.Format at the top level.
This feature is useful in streaming formatters.