
Boost : 
Subject: Re: [boost] Boost.Algorithm design question
From: lcaminiti (lorcaminiti_at_[hidden])
Date: 20111006 17:00:41
Dave Abrahams wrote:
>
> on Thu Oct 06 2011, lcaminiti <lorcaminitiATgmail.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<iterator_traits<Iter>::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<A,B>, where A != B.
>
I see, how about the semantic of EqualityComparable<A, B> with A != B
is up for discussion :)
Here's a (funny) way I could satisfy the EqualityComparable<A, B>
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<A, B> 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/BoostAlgorithmdesignquestiontp3876424p3879948.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