[Patch] First bits of the algo merge

[Howard Hinnant]

On Dec 13, 2005, at 7:22 AM, Paolo Carlini wrote:

> +      return std::mismatch(__first1, __last1, __first2,
> +			   __gnu_cxx::__ops::equal_to());
>      }
>

> +  struct equal_to
> +  {
> +    template<typename _Lhs, typename _Rhs>
> +      bool
> +      operator()(const _Lhs& __lhs, const _Rhs& __rhs) const
> +      { return __lhs == __rhs; }
> +  };

I tried this design once and got bitten.  Although I think this is  
probably conforming (not positive, I'd have to look it up).  If I  
correctly recall I think proxy iterators were involved.  And we don't  
have to support them.  Just it would be polite to do so.

Run a test with vector<bool>.  Oh wait, that might actually work  
because I'm noticing in _Bit_reference:

     bool
     operator==(const _Bit_reference& __x) const
     { return bool(*this) == bool(__x); }

But note that in general a proxy may not have an operator==.  It may  
depend upon implicitly converting to its value_type.  But once the  
proxy is trapped in the equal_to::operator, there's no chance for  
that conversion to happen.

Like I said, I don't /think/ you'll fail any conformance tests with  
this one.  But you may alienate a customer or two.

If we want to accommodate those customers, a simple fix is:


+      return std::mismatch(__first1, __last1, __first2,
+			   __gnu_cxx::__ops::equal_to<value_type1, value_type2>());
      }


+  template<typename _Lhs, typename _Rhs>
+  struct equal_to
+  {
+      bool
+      operator()(const _Lhs& __lhs, const _Rhs& __rhs) const
+      { return __lhs == __rhs; }
+  };

And as you've observed, rvalue references always work their way into  
the conversation, ;-) an even better fix would be:

+  template<typename _Lhs, typename _Rhs>
+  struct equal_to
+  {
+      bool
+      operator()(_Lhs&& __lhs, _Rhs&& __rhs) const
+      { return __lhs == __rhs; }
+  };

Now you can accommodate proxy iterators AND people who neglect to  
qualify their op== with const. :-)

-Howard