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

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


View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at