rel_ops (was Re: GCC 3.1 Release)

Gabriel Dos Reis
Fri Apr 19 12:54:00 GMT 2002

Phil Edwards <> 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