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: Joe Buck <Joe dot Buck at synopsys dot com>
- To: gdr at codesourcery dot com (Gabriel Dos Reis)
- Cc: Joe dot Buck at synopsys dot COM (Joe Buck), phil at jaj dot com (Phil Edwards),Richard dot Kreckel at uni-mainz dot de,gdr at codesourcery dot com (Gabriel Dos Reis),mark at codesourcery dot com (Mark Mitchell),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 dot Bauer at uni-mainz dot de (Christian Bauer)
- Date: Fri, 19 Apr 2002 14:34:40 -0700 (PDT)
- Subject: Re: rel_ops (was Re: GCC 3.1 Release)
> | 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.