Re: Defining Non-Member Functions for Template Member Types
On Apr 1, 3:52 am, "Alf P. Steinbach" <al...@start.no> wrote:
* flounder:
The compiler is unable to find a match for the call to
munge() and operator==() in is_equal() below. Can someone
post an explanation and/ or suggest a workaround?
template<class T>
struct Foo {
struct Bar {};
};
template<class T>
bool operator==(const typename Foo<T>::Bar&, const typename
Foo<T>::Bar&);
template<class T>
void munge(typename Foo<T>::Bar* );
inline bool
is_equal(Foo<int>::Bar x, Foo<int>::Bar y)
{
munge(&x);
return x == y; // no operator "==" matches these operand=
s
}
I googled.
See
<url:http://www.codeguru.com/forum/archive/index.php/t-395268.html>;
"non-deduced context".
However while it seems the facts there are OK, the
rationalization there seems very fishy to me. Perhaps that
rationalization is the standard's rationale (I'm too lazy to
check). But in a context like above I see no good reason why
the language could not have permitted the matching: there can
be only one match.
The problem is that in the general case, at least, the compiler
would have to verify all of the possible expansions of Foo<>.
Suppose, for example, one of them expanded to contain:
typedef typename Foo<int>::Bar Bar ;
.. (That would make the call ambiguous.) It's easy for a human,
looking at the template definition, and knowing that there are
no explicit specializations, to realize that this could not be
the case, but this realization is based on a higher degree of
logic than compilers are capable of.
I can see a bad reason, though, namely treating all types the
same way, and the above would indeed be problematic with Bar a
typedef'ed name, e.g. for 'int'.
Exactly. And you don't know what Bar will be in Foo<T> until
you've instantiated Foo<T>.
The problem is that we humans (most of us, anyway) can think
very well in abstract terms, along the lines of "for all T...".
Machines can't, or at least, current compilers don't incorporate
any technology that can.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34