Re: [Boost-users] EqualityComparable of unordered containers

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