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: Phil Edwards <phil at jaj dot com>
- Cc: Richard dot Kreckel at uni-mainz dot de, Gabriel Dos Reis <gdr at codesourcery dot com>, Joe Buck <Joe dot Buck at synopsys dot com>, Mark Mitchell <mark at codesourcery dot com>, "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 Bauer <Christian dot Bauer at uni-mainz dot de>
- Date: 19 Apr 2002 21:54:02 +0200
- Subject: Re: rel_ops (was Re: GCC 3.1 Release)
- Organization: CodeSourcery, LLC
- References: <flwuv7iljq.fsf@jambon.cmla.ens-cachan.fr> <Pine.LNX.4.21.0204172043020.1278-100000@higgs.physik.uni-mainz.de> <20020417151320.A25369@disaster.basement.lan>
Phil Edwards <phil@jaj.com> writes:
| On Wed, Apr 17, 2002 at 08:52:50PM +0200, Richard B. Kreckel wrote:
| > 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.
|
| The problem is not that they take precendence /over/ other operators, it's
| that they don't allow other operators to take precedence over themselves.
:-)
You're right.
But it is also true that in some cases, they do take precedence over
some operators.
The crux being that sometimes, the standard conversion derived -> base
is attempted only when there is no match that would could solve the
overload; and it such cases, things break. See the example I just posted.
| They become equal candidates. Then the compiler pukes out due to the
| ambiguity. (To see this, use the rel_ops operators with vector or string
| iterators, /without/ the recently applied patch.)
|
| At least, that seems to be the problem. Gaby?
Yes, in the specific case of __normal_iterator, that is what happens.
| In a perfect world (or at least in mine *grin*), we could tell the compiler
| that, in the case of ambiguous matches, check to see if one of the functions
| is in the std::rel_ops namespace, and if so, temporarily discard that one,
| and see if the ambiguity remains. (Blue-sky idea, probably flaky.)
That isn't conforming and I'm not sure I would like to implement that
feature, I might be definitely labelled "anti-rel-ops" ;-)
[ Phil, I'm getting mailer-daemon notices telling me that your address
isn't valid. What is up? ]
-- Gaby