This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: rel_ops (was Re: GCC 3.1 Release)
- From: Joe Buck <Joe dot Buck at synopsys dot com>
- To: Richard dot Kreckel at uni-mainz dot de
- Cc: gdr at codesourcery dot com (Gabriel Dos Reis),Joe dot Buck at synopsys dot COM (Joe Buck),mark at codesourcery dot com (Mark Mitchell), phil at jaj dot com (Phil Edwards),gcc at gcc dot gnu dot org (gcc at gcc dot gnu dot org), bkoz at redhat dot com (bkoz at redhat dot com),libstdc++ at gcc dot gnu dot org (libstdc++ at gcc dot gnu dot org),Christian dot Bauer at uni-mainz dot de (Christian Bauer)
- Date: Wed, 17 Apr 2002 12:03:31 -0700 (PDT)
- Subject: Re: rel_ops (was Re: GCC 3.1 Release)
Richard Kreckel writes:
> Sorry, that beats me. When you overload or specialize any operator> then
> a templated operator> that would match the same signature should not take
> precedence, be it in some namespace or not. And it doesn't seem to happen
> in GCC as far as I can see and it would be a freaking bug if it happened
> as far as I can tell. Gaby, I have repeatedly asked you to explain the
> problems you keep mentioning but you never answered. Could someone please
> enlighten me and provide a scenario where the operators in std::rel_ops
> take precendence over operators that would have been selected otherwise.
Before the bug was fixed, the problem was not that std::rel_ops::operator!=
took precedence over the != for __normal_iterator, it was that neither one
took precedence (there was an ambiguity). This meant that some valid
programs failed to compile.
The bug is now fixed for 3.1, so let's not fight about it any more.
Users of 3.0.4 might have some difficulties if they have programs that
say
using std::rel_ops;
and then use vector iterators. A workaround is to change code that uses
!= on iterators from something like
iter != vec.end()
to
!(iter == vec.end())
for 3.0.x if you see a compilation failure. This will not be needed for
3.1.