Remove algo duplication

[François Dumont]

I just wanted to let you know that I am working on adopting the 
templated member functions, it does indeed greatly simplified the code 
in predefined_ops.h.

On 09/15/2013 11:41 AM, Marc Glisse wrote:
> On Sun, 15 Sep 2013, Christopher Jefferson 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.
>
> That doesn't work for input iterators that return prvalues, does it? 
> (and please let's not rely on the fact that only input iterators can 
> return prvalues)
>
>> 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!
>
> One good point about the iterator thing is that you know it does the 
> same thing as using operator< directly, since that's what it does. An 
> example where you can notice a difference is for instance with an 
> input iterator whose operator* returns a prvalue and an operator< that 
> takes its arguments by value. Then with *i<*j you get copy elision, 
> whereas std::less<void>(*i,*j) has to perform 2 moves. We may decide 
> to ignore this difference, I am just giving an example where using 
> __less would be a detectable change for users.
>
> Maybe having 2 copies of the algos isn't bad enough to deserve so much 
> effort...

I hope it doesn't put too much effort on you. On my side it is ok, I 
find it interesting to complete. Of course we could limit this effort to 
the algorithms that are using the more code. I prefer to _always_ use 
this approach for consistency in the library but when the algo logic 
only takes about 5-10 lines of code then the result is bigger than with 
2 distinct implementations.

For info, what made me start this effort is to be able to use internally 
the algo logic without paying for the extra concept/debug/parallel code. 
For instance the containers already have a debug implementation so it is 
useless to have debug checks in the normal implementation behind the 
debug one. I would like each layer to be correctly segregated so that we 
can perfectly control what is done when any special mode is activated.
>
> Using the preprocessor would be another way to remove duplication.
>
For simple algos perhaps but for the most complex ones it might be 
difficult to read and so to maintain. I learned to avoid preprocessor as 
much as possible.

François