Re: [Boost-users] EqualityComparable of unordered containers

From: Daniel Krügler (dsp_at_[hidden])
Date: 2008-08-21 03:48:36

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 <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 ;-)
>>
>> 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