|
Boost : |
Subject: Re: [boost] [log] Comments
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2010-03-16 14:44:08
AMDG
Andrey Semashev wrote:
> On 03/16/2010 08:35 PM, Steven Watanabe wrote:
>> 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.
Why does it have to compile? The obvious implementation
would be for this attr to produce a string when invoked, which
obviously cannot be compared to an int. Anyway, this seems
like yet another reason to remove Boost.Format from the attr
function.
> 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).
I would expect this to compile, but issue a warning about converting
int to bool. This conversion is a general problem of C++. I don't
see that you gain much by forbidding it.
>>> 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.
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.
>> 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.
From what you've said, this use of Boost.Format
conflicts with things that I consider much more
important.
In Christ,
Steven Watanabe
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk