On Aug 20, 2008, at 2:20 AM, 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 ;-)
But I let it settle for a while - as I already said: I might have a bit too strict point of view on this and I would really appreciate further comments.
I don't know if what I'm going to say was what David was thinking of, but... If a predicate function object has several "operator ()" overloads, they should be conceptually identical. Ideally, they should be "const" member functions that depend only on the values of the inputs and any internal state data members. Even without that, your predicate class should represent ONE kind of evaluation criteria to pass judgement on. Your nightmare predicate would have to have all the "operator ()" inconsistent with each other, i.e. differing criteria. That would make it useless, considering you can't choose which overload you get in normal use. You can choose a specific version with Stupid C++ Tricks involving casting the inputs and/or the member function, but that won't help with generic (template- based) code. Testing operations that aren't the same shouldn't be part of the same predicate class. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com