Re: [boost] Boost.Algorithm design question

Subject: Re: [boost] Boost.Algorithm design question
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-10-06 15:51:57

on Thu Oct 06 2011, Marshall Clow <mclow.lists-AT-gmail.com> wrote:

> On Oct 6, 2011, at 11:05 AM, lcaminiti wrote:
>
>> 
>> Dave Abrahams wrote:
>>> 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
>
> That seems right to me.

It seems right to you because everybody overlooks the semantic part of
concept requirements, which he left out.  What does the algorithm *do*?
What are the semantic constraints imposed by EqualityComparable<T,U>
that make the algorithm do *that*?

When T==U then you say EqualityComparable *is an equivalence relation*,
and you say the algorithm "Returns true iff no member of [ first, last )
is equal to val."  You don't have to say anything about which one goes
on the left or right side of the ==.  You can understand the semantics
of that algorithm in terms that mean something more than a pile of
syntax.

I don't believe any description of the algorithm where T!=U can be as
clear or as meaningful.  Algorithms that use operators should be
specified in terms of the meanings of those operators rather than the
expressions used to implement the algorithms.  We have the versions
taking functions for the other cases.

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