Boost logo

Boost :

Subject: Re: [boost] Boost.Algorithm design question
From: lcaminiti (lorcaminiti_at_[hidden])
Date: 2011-10-06 17:00:41


Dave Abrahams wrote:
>
> on Thu Oct 06 2011, lcaminiti <lorcaminiti-AT-gmail.com> wrote:
>
>> Dave Abrahams wrote:
>>>
>>> I don't think you can evaluate these choices just by looking at the
>>> implementations. Before anyone else votes option 1, I'd like to see
>>>
>>
>> Well, I'm not so sure I like option 1 anymore... if option 1 was an
>> oversight in STL then there is no sense in perpetuating the specification
>> error in Boost.Algorithm (perhaps Boost.Algorithm should then go with
>> option
>> 2 and explain the rationale of why it's different than what STL does for
>> example with std::find).
>>
>>> somebody write the description of the algorithm, including the concept
>>> requirements. With option 2, we know that == has to be an equivalence
>>> relation. The semantics in option 1 are a lot fuzzier.
>>>
>>
>> Good point! I'll try to start :)
>>
>> template< typename Iter, typename Val >
>> requires
>> InputIterator<Iter>,
>> EqualityComparable&lt;iterator_traits&lt;Iter&gt;::value_type,
>> Val>
>> bool none_of_equal ( Iter first, Iter last, Val const& val ) ; // option
>> 1a
>
> What you failed to do here was to describe the semantic requirements on
> EqualityComparable&lt;A,B&gt;, where A != B.
>

I see, how about the semantic of EqualityComparable&lt;A, B&gt; with A != B
is up for discussion :)

Here's a (funny) way I could satisfy the EqualityComparable&lt;A, B&gt;
requirement:

#include <vector>
#include <algorithm>

struct orange {
    int weight;
};

struct apple {
    int weight;
};

bool operator== ( orange const& l, apple const& r )
    { return l.weight == r.weight; } // comparing apples with oranges?!

int main ( ) {
    std::vector<orange> v(2);
    std::find(v.begin(), v.end(), apple());
    return 0;
}

No type conversion, EqualityComparable&lt;A, B&gt; is some sort of
equivalence that can be defined among the different types without converting
them into one another... isn't that confusing :)

I am starting to find option 1 confusing... (like the example above). Maybe
is best to go with option 2 for the _equal functions requiring the types to
be the same because that's the commonly understood semantic of ==. For
comparing apples with oranges (and other strange things), we can use the
predicate version of the algorithms.

--Lorenzo

--
View this message in context: http://boost.2283326.n4.nabble.com/Boost-Algorithm-design-question-tp3876424p3879948.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk