Re: [Patch] First bits of the algo merge

[chris jefferson <caj at cs dot york dot ac dot uk>]

Howard Hinnant wrote:
> ...
> 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.
>
Out of interest, do you have an implementation of what you consider to
be a "good" proxy iterator? I'd be interested to see how much of
<algorithm> supports such things (I suspect it will be quite a bit, but
not all, in particular I think the sorts won't work, but it might not be
hard to fix).
>
> +      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; }
> +  };
>
I seem to remember way back in the depths of time I actually had this in
the first version I submitted, but it was decided the version we now use
was much more compact. I don't imagine it would be too hard to fix :)
> 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. :-)
>
Managed to get rvalue references to make world peace yet? ;)

Chris