rel_ops (was Re: GCC 3.1 Release)

Gabriel Dos Reis gdr@codesourcery.com
Fri Apr 19 12:54:00 GMT 2002


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



More information about the Libstdc++ mailing list