Boost logo

Boost Users :

From: Daryle Walker (darylew_at_[hidden])
Date: 2008-08-22 03:25:45


On Aug 21, 2008, at 9:23 PM, David Abrahams wrote:
> on Tue Aug 19 2008, Daniel Krügler <dsp-AT-bdal.de> wrote:
>> David Abrahams wrote:
>>> on Tue Aug 19 2008, Daniel Krügler <dsp-AT-bdal.de> wrote:
>>>>
[SNIP]
>>>> Or to express the problem in different words: In general
>>>> there exists a one-to-many relation between a class
>>>> type and it's operator() overloads [acting as predicates],
>>>> so the class-type alone is not sufficient to define
>>>> an equality of *one* special operator() overload, which
>>>> we are interested in. Therefore the predicate equality needs
>>>> to be restricted to a given predicate (a given operator()
>>>> overload).
>>>
>>> I think you're over-engineering this. It's not unreasonable to
>>> require operator== to make sense in this context.
>>
>> This answer is a bit too short for me and has not
>> the convincing power which we usually get from your
>> contributions ;-)
>
> Thanks; I've been under the weather. Still, I don't know how to
> say it
> much better.

Have you seen my responses yet? I think I got what you were saying.
Basically, if there's a one-to-many relationship between a predicate
class and its "operator ()" overloads, that means that the various
overloads aren't consistent with each other. Such a predicate class
is useless, especially in generic code, where you can't choose which
overload is chosen. (Note that the amount of state, if any, is
irrelevant here.) The predicate has to represent an ideal criteria
and _all_ the "operator ()" overloads have to be conceptually
identical in supporting that ideal.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net