Remove algo duplication

[Christopher Jefferson]

One final comment, perhaps (and I have been guilty of this in the
past) rather than trying to 'big bang' all the functions at the same
time, we should try doing things more incrementally? Perhaps just the
sort functions (or even, just std::sort for example), while we get the
interface and details settled down.


On 15 September 2013 09:57, Christopher Jefferson <chris@bubblescope.net> wrote:
> I have not looked carefully at predefined_ops.h, but I can show you
> some of the previous code which I know has caused problems for this
> kind of simplification. I attach it below.
>
> I agree with Marc, I think templated member functions are the way to
> go. For example, I would use objects like this:
>
> struct __less {
> template<typename T, typename U>
> bool operator()(T& t, U& u) { return t < u; }
> };
>
> Note the missing 'const' on T& and U& is intentional.
>
> I attach a list of some of the weirder things I remember seeing break,
> and some outline of comparitors I think might be best.
>
> Note I have NOT tested all the cases of these comparitors, just a
> suggestion as a direction we could go in.
>
> Francois:I assume it is these kinds of problems which made we want to
> change all the predicates to take iterators directly, and do the
> de-referencing in-predicate. However, that does radically change
> almost every algorithm. Do you have any examples of where my suggested
> __less above does not work, and your redirection does? While I'm not
> 100% opposed to such a big change, I would want it to have excellent
> justification!
>
> Chris
>
>
> On 9 September 2013 20:59, Paolo Carlini <paolo.carlini@oracle.com> wrote:
>> Hi,
>>
>> as far as I'm concerned, the sheer size of predefined_ops.h is the most important issue. I still can't convince myself on an intuitive level that for forwarding so much code is necessary.
>>
>> That said, since the real difficulty of the task boils down to proper fowarding, it seems "obvious" to me that a complete patch should come with corresponding tests, minimally exercizing the algorithms for a typical proxy iterator type, maybe even the available vector<bool>::iterator, or a specific new test type (more "nasty" than vector<bool>::iterator? In the past Howard often discussed some, in various contexts). I realize it would be a lot of work and in any case I can't promise that I would immediately approve the patch (for the reason above)
>>
>> Paolo
>>
>>