On Aug 21, 2008, at 9:23 PM, David Abrahams wrote:
on Tue Aug 19 2008, Daniel Krügler
wrote: David Abrahams wrote:
on Tue Aug 19 2008, Daniel Krügler
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