Re: First patch to simplify <algorithm>

[Jonathan Wakely <cow at compsoc dot man dot ac dot uk>]

On Sun, Dec 05, 2004 at 10:29:50PM +0100, Gabriel Dos Reis wrote:

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

I'd say no; the point of the concept-checks is to turn a scary
compiler error into a nice, cuddly one that contains the string
"EqualityComparable".

> What this means is that adjacent_find() (both overloads) should
> probably be splitted into two pieces:
> 
>   (1) __do_adjacent_find() -- better names welcome :-)
>       Does the core job; no concept checking.
>   (2) both adjacent_find() do their concept checking, then move on
>       calling __do_adjacent_find() to do the real job.
> 
> E.g.
> 
>   template<typename _Forward>
>     inline _Forward
>     adjacent_find(_Forward __first, _Forward __last)
>     {
>        typedef typename iterator_traits<_ForwardIterator>::value_type 
>            value_type;
>        __glibcxx_function_requires(_EqualityComparableConcept<value_type);
>        return std::__do_adjacent_find(__first, __last, __gnu_cxx::equal());
>     }
> 
> Similar for the other overload.

This might be overkill, since the concept-checks shouldn't add any
runtime code there shouldn't be any harm if the extra checks in the
overload taking a predicate are applied to both overloads (I think).

Does splitting them buy something I'm missing?

jon

-- 
Emacs is a nice OS - but it lacks a good text editor.
That's why I am using Vim.
	- Anonymous