This well-formed complete source is rejected by g++, but compiles fine
with comeau online 4.3.3 BETA August 4, 2003.
A related discussion on clc++
lang.c++/msg/1475f4e8f1ff9982
struct A
{
template<class Tvoid operator<<(T&);
};
template<class Tstruct B {};
template<class Tvoid operator<<(A&, B<T>&);
int main()
{
A a;
B<Ab;
a << b;
}
[max@localhost exp]$ g++ -v -save-temps -Wall exp.cpp -o exp
Using built-in specs.
Target: i386-redhat-linux
Configured with: /configure /usr /usr/share/man --
infodir=/usr/share/info
checking=release
libunwind-exceptions ,c++,
objc,java,f95,ada /usr/lib/jvm/
java-1.4.2-gcj-1.4.2.0/jre
Thread model: posix
gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)
/ -E -quiet -v -
D_GNU_SURCE exp.cpp -Wall -fpch-preprocess -o exp.ii
ignoring nonexistent directory "/
i386-redhat-linux/include"
#include "" search starts here:
#include <search starts here:
/
/
linux
/
/usr/local/include
/
/usr/include
End of search list.
/ -fpreprocessed exp.ii -quiet
-dumpbase exp.cpp -auxbase exp -Wall -version -o exp.s
GNU C++ version 4.0.1 20050727 (Red Hat 4.0.1-5) (i386-redhat-linux)
compiled by GNU C version 4.0.1 20050727 (Red Hat 4.0.1-5).
GGC heuristics: ggc-min-expand=64 ggc-min-
heapsize=64417
exp.cpp: In function 'int main()':
exp.cpp:13: error: ambiguous overload for 'operator<<' in 'a << b'
exp.cpp:3: note: candidates are: void A::operator<<(T&) [with T = B<A>]
exp.cpp:7: note: void operator<<(A&, B<T>&) [with T = A]
# 1 "exp.cpp"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "exp.cpp"
struct A
{
template<class Tvoid operator<<(T&);
};
template<class Tstruct B {};
template<class Tvoid operator<<(A&, B<T>&);
int main()
{
A a;
B<Ab;
a << b;
}

Additional Comments From pinskia at gcc dot gnu dot org 2005-08-26 15:01
It started to fail after 20041211.

Additional Comments From mmitchel at gcc dot gnu dot org 2005-08-27 21:49
Nathan --
This change comes from:

2005-04-03 Nathan Sidwell <nathan (AT) codesourcery (DOT) com>

PR c++/20723
* pt.c (more_specialized_fn): Member functions are unordered wrt
non-members. Conversion operators are unordered wrt other
functions.

I looked at DR124, but I didn't see anything to justify the "member functions
are unordered wrt non-mebers" claim. What am I missing?
-- Mark

Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-15 21:19
Nathan, do you have any insights about this PR?

Additional Comments From nathan at gcc dot gnu dot org 2005-09-16 07:30
I shall take a look

Additional Comments From nathan at gcc dot gnu dot org 2005-09-16 13:37
This is a piece of underspecification in the resolution of DR 214
(#214). That
basically tells one to compare pairs of arguments. But in this case we have a
member function and a non-member function -- how should we treat the this
pointer of the member function and the first arg of the non-member function?

As the algorithm did not give any indication as to how to order these, I made
them unordered.

Experimentation using the edg 3.6 frontend I find it to skip the first argument
of both functions (either an explicit arg or implicit this pointer) if either
function is a member function. The alternative, of comparing the this pointer
arg with the explicit arg of the other function requires treating the this
pointer argument as-if it were a reference to the object (otherwise it'll never
deduce in either direction as the explicit argument must be a by-value or
by-reference object). Experimentation shows the EDG front end does not take
that approach.