Remove algo code duplication

[François Dumont]

I though that I wouldn't have to take care of this kind of use case but 
you are right I better handle it correctly.

So I am going to write tests challenging the number of constructors 
invoked when algos are used with or without my patch, in C++98 and C++11 
modes.

To be continued...



On 05/02/2012 10:10 PM, Marc Glisse wrote:
> [Jonathan already answered most of it]
>
> On Wed, 2 May 2012, François Dumont wrote:
>
>>>> 2. Compatible with existing code, code submitted by Christopher 
>>>> last time will still compile. To do so I used 
>>>> std::iterator_traits<>::reference type so that if the iterator is 
>>>> not const then the operator do not have to take const reference or 
>>>> to be const qualified neither. For the same reason I have also 
>>>> avoided some const qualifiers on the introduced functors.
>>>
>>> It probably doesn't matter, but the difference with the current code 
>>> can be seen. With -fno-elide-constructors you perform copies, 
>>> operator< is always given an lvalue, etc.
>> You mean functor copies, right ? I expect the compiler to optimize 
>> them away even if there are options to forbid him to do so.
>
> I mean value copies, performed by the functor.
>
> #include <iostream>
> struct A {
>   A(){std::cout << "A()\n";}
>   A(A const&){std::cout << "A(A const&)\n";}
>   A(A &&){std::cout << "A(A &&)\n";}
> };
> bool operator<(A,A){return true;}
> struct less {
>   bool operator()(A a,A b)const{return a<b;}
> };
> struct Iter {
>   A operator*()const{return A();}
> };
>
> int main(){
>   Iter x;
>   std::cout << "hello\n";
>   *x < *x; // all copies elided
>   std::cout << "pause\n";
>   less()(*x,*x); // 2 copies can't be elided
>   std::cout << "bye\n";
> }
>
> hello
> A()
> A()
> pause
> A()
> A()
> A(A const&)
> A(A const&)
> bye
>
>
> I am not saying it is necessarily a bad thing, just that the 
> difference is noticable. Note that the functor less posted by Jonathan 
> would keep 2 move constructors instead of the 2 copy constructors.
>
> (note: I am not sure that's what I had in mind when I wrote that 
> email, I can't remember exactly)
>