Daryle Walker wrote:
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.
Thank you very much for your reply and apologies for my late response! My main concern was that the standard should not be too intrusive, but your arguments made me reflect again on this. Users should easily be able to separate their predicate "bundle", if their see strong need for such a bundle, e.g. instead of struct S { bool (*scmp)(const char*, const char*); explicit S(streq_t sc = ...) : scmp(sc) {} // Stateless predicate: bool operator()(int a, int b) const { return a == b; } ... // other stateless predicates // Statefull predicate: bool operator()(const char* a, const char* b) const { return scmp(a, b); } }; they could (and probably should) write: struct SPure { // Stateless predicate: bool operator()(int a, int b) const { return a == b; } ... // other stateless predicates }; struct S : SPure { bool (*scmp)(const char*, const char*); explicit S(streq_t sc = ...) : scmp(sc) {} // Statefull predicate(s): bool operator()(const char* a, const char* b) const { return scmp(a, b); } }; Inheritance is neither required nor usually wanted, but if some-one *needs* this bundle (because of external requirements) she can realize this, if she wants that. Thank you for your help! - Daniel