This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/16053] Fails to identify overload
- From: "igodard at pacbell dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 18 Jun 2004 23:13:10 -0000
- Subject: [Bug c++/16053] Fails to identify overload
- References: <20040618112043.16053.igodard@pacbell.net>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From igodard at pacbell dot net 2004-06-18 23:13 -------
Well, as I understand it, an exact match on a non-template argument trumps any template match in the same position of an overload; this is the essence of specialization. I also understand that a "friend" declaration within a class is the equivalent (for identification purposes) to the same declaration outside the class with appropriate substitutions, i.e. friendship is irrelevant for call indentification, and only matters in the body.
In your reduced case, after removing the "friend" to outside the class manually (to mimic export of friends as performed by the compiler), your example becomes equivalent to:
class B {};
template <typename> struct A { };
template <typename T, typename U>
void operator<< (A<T> &, const U &);
template<typename T>
void operator<<(A<T> &, const B &);
int main() {
A<int> d;
d << B();
}
which is exactly what you would have written had you *not* had to make one of the overloads a friend.
Expessed in this form it is clear that the latter overload is essentially a specialization of the former and the call should identify the latter. Which in fact it does if you compile the rewritten case.
Now it seems to me that identification should not depend upon whether a function had been made a friend or not. I don't understand the standard enough to know whether my two functions (as rewritten to remove "friend") are ambiguous, but if they are they should be ambiguous in both your version and my rewrite. Or neither. Half and half is unreasonable, as these are clearly the same declarations.
I believe (in my ignorance) that the compiler has it right on the rewritten version, and is failing to correctly export the friend to the surrounding scope in your version; considering the number of other bugs in friend export this would not be surprising.
Ivan
--
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16053