Re: [Boost-users] EqualityComparable of unordered containers

From: David Abrahams (dave_at_[hidden])
Date: 2008-08-22 11:58:46

on Thu Aug 21 2008, Daryle Walker <darylew-AT-hotmail.com> wrote:

> 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?  

Yes

> 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.

I think that sounds like what I meant.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com