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: Gabriel Dos Reis <gdr at codesourcery dot com>
- To: Joe Buck <Joe dot Buck at synopsys dot com>
- Cc: Richard dot Kreckel at uni-mainz dot de, gdr at codesourcery dot com (Gabriel Dos Reis), 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: 19 Apr 2002 21:47:30 +0200
- Subject: Re: rel_ops (was Re: GCC 3.1 Release)
- Organization: CodeSourcery, LLC
- References: <200204171903.MAA17288@atrus.synopsys.com>
Joe Buck <Joe.Buck@synopsys.com> writes:
| 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).
std::rel_ops::operator!= can take precedence in specific cases (not
for __normal_iterator). See the example I just posted.
-- Gaby