Re: rel_ops issues

[Joe Buck <jbuck at racerx dot synopsys dot com>]

[ see prev discussion: this is for GNATS case 2405 ]

> | Without it there is a conflict between the two operator!= definitions.
> | This third definition will be preferred to either of the other two
> | for != on two vector iterators.
> | 
> | Objections?
> 
> Since __normal_iterator is a class the library put in for its own
> purposes, it should ensure it works properly without introducing
> unwanted semantics in user programs.  That pretty much exclude the
> using-declaration and using-directive.

Yes, but I did not propose that.  We are now in agreement that the library
should not use the rel_ops stuff anywhere.

> In fact, the solution is to
> overload operator!=, operator<, operator>, operator<= and operator>=
> for __normal_iterator. 

Yes, but they are already overloaded.  The problem is that we need
additional versions to eliminate conflicts with rel_ops, as I suggested.

Currently the library defines

template<typename _IteratorL, typename _IteratorR, typename _Container>
inline bool
operator!=(const __normal_iterator<_IteratorL, _Container>& __lhs,
	   const __normal_iterator<_IteratorR, _Container>& __rhs)
{ return !(__lhs == __rhs); }

Note that the two argument types are different.  This means that this
template is not considered strictly better than the rel_ops definition

template <class _Tp>
inline bool operator!=(const _Tp& __x, const _Tp& __y) {
  return !(__x == __y);
}

so there is a conflict.  This problem is solved by including an extra
definition for when the two types are the same, that is,

template<typename _Iterator, typename _Container>
inline bool
operator!=(const __normal_iterator<_Iterator, _Container>& __lhs,
	   const __normal_iterator<_Iterator, _Container>& __rhs)
{ return !(__lhs == __rhs); }