Re: First patch to simplify <algorithm>

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

caj <caj@cs.york.ac.uk> writes:

| Gabriel Dos Reis wrote:
| 
| >caj <caj@cs.york.ac.uk> writes:
| >
| >| +  template<typename _ForwardIterator>
| >| +    _ForwardIterator
| >| +    adjacent_find(_ForwardIterator __first, _ForwardIterator __last)
| >| +    {
| >| +      // concept requirements
| >| +      __glibcxx_function_requires(_EqualityComparableConcept<
| >| +	    typename iterator_traits<_ForwardIterator>::value_type>)
| >| +      return adjacent_find(__first, __last,
| >| +             __default_eq_pred<typename iterator_traits<_ForwardIterator>::
| >| +			   value_type>());
| >
| >With the suggestions I made, the above simply reads
| >
| >         return std::adjacent_find(__first, __last, __gnu_cxx::equal());
| >
| >No, typename-fu. You can leave the "concept checking"  part to the
| >"forwarded-to" more general algorithm.  And you should make the
| >resulting function inline.
| >(Note the explicit qualification, too.)
| >
| >
| It's definatly a thousand times nicer :) The only thing that I
| disagree with (probably because I don't know enough) is if you can
| still remove that concept requirement. I only left one concept
| requirement (EqualityComparable) and I don't think you are allowed to
| remove that, as the concept requirements in adjacent_find won't pick
| up directly that *__first isn't EqualityComparable (it will just check
| that __gnu__cxx::equal::operator() takes two parameters of type
| _ForwardIterator). Of course that particular concept requirement is
| not entirely needed anyway, because the code simply won't compile
| anyway if it isn't true, but I'm not sure if it can be removed....

You're probably right.  Let it there for the moment.

-- Gaby