rel_ops (was Re: GCC 3.1 Release)

[Joe Buck]

> | Conflicts will only occur if the user definition (or more specific
> | definition in the system library) permits the arguments to be of different
> | types but allows them to be of the same type.  If this happens, then it is
> | possible that, for a call to operator!= with two arguments that are of
> | exactly the same type, the two definitions of operator!= will be seen as
> | equal cost, and neither will be seen as a specialization of the other,
> | so the compiler will report an ambiguity.
> 
> Not always.  Sometimes, it will take the std::rel_ops version because
> it provides a "best match" (according to the standard).

Right.  For example, if I define

bool operator!=(const foo&, const foo&);

and then I have a class bar that derives from foo, the std::rel_ops
version will be a better match for 

bar b1, b2;
...
b1 != b2;

because the exact template match is better than the standard conversion
to the base class.

However, anyone who does a using directive to bring in rel_ops is saying
that it is OK to define != in terms of ==, so this doesn't matter.  The
only cases that are problems are those in which neither is preferred.

> | The way to solve it is to add a third definition that will be seen by
> | the compiler as more specific than either of the alternatives.
> 
> Actually, this might not be always practical.

If so, the alternative is to be sure not to use rel_ops. :-)  However,
since the standard library has to support rel_ops to be correct, at least
the standard library implementers need to use such techniques.