Re: First patch to simplify <algorithm>

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

Jonathan Wakely <cow@compsoc.man.ac.uk> writes:

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

What precisely is overkill about it?  Could you articulate?
(You mention runtime overhead but that is just one axis which is not
being disputed here).

[...]

| Does splitting them buy something I'm missing?

Get the code straight.  Which is all this is about.

But, I'm not fanatic about.  I would wait and see the real patch
instead of splitting hears now.

-- Gaby