rel_ops (was Re: GCC 3.1 Release)
Fri Apr 19 14:34:00 GMT 2002
> | 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.
More information about the Libstdc++