Re: template friends, specialization usage change with gcc 4.0.1
Tom Mander wrote:
I've found a solution to my problem, but I'm interested in
understanding more of what I am seeing in a slightly obtuse
symbol binding issue. This code was written a long time ago by
someone else. I'd be interested in any insight into what gcc4
(4.0.1) is doing and why it is different to gcc3, and
confirming that what I am seeing is valid behaviour (i.e. more
ANSI standards compliant) rather than a compiler bug.
Take templated class Hash:
template <class K, class V>
class Hash
{
public:
enum { DEFAULT_SIZE = 64 };
typedef unsigned int (*HashFunc)(const K&);
Hash(int size = DEFAULT_SIZE, HashFunc = hashFunc);
The name lookup of hashFunc is a bit tricky, and corresponds to
a case where g++ 4 and up have changed to be more conform to the
standard. Basically, what has changed is that the standard (and
g++ 4...) uses a two phase lookup: if a name is "dependant", it
is looked up at the point of instantiation, using somewhat
special rules, but otherwise, it is looked up normally at the
point of definition.
By my reading of the standard (particularly ?14.6.2.2), the
identifier hashFunc is NOT dependant, as unexpected as that
seems given its use. (While it seems intuitively crazy, this is
actually very coherent -- only in very exceptional cases does
use determine anything about how a symbol is interpreted.) That
means that it should be looked up and bound at the point where
the template is defined. If no symbol hashFunc is visible at
this point, it is an error. If a symbol is visible, it is bound
at this point; no later declarations are taken into account.
(I'm pretty sure that this is also true with regards to
overloading, and that later declarations cannot add functions to
the overload set either. Pretty sure, but not 100%.)
...
};
class A {
...
friend unsigned int hashFunction(const A&); //used by Hash::Hash in
gcc3
friend unsigned int hashFunc<A>(const A&); //used by Hash::Hash in
gcc4
};
class B {
...
Hash<A, B*> _children;
...
};
To successfully link using gcc3, I need the following defined:
unsigned int hashFunc(const A& a)
{
...
}
While for gcc4, I need:
template<> unsigned int hashFunc<A>(const A& a)
{
...
}
My gut tells me that what gcc4 requires looks more correct,
but nm shows that gcc3 definitely binds to the former, and
gcc4 to the latter. Gcc4 seems to be implicitly using the
fully specialized friend template method, whereas gcc3 looks
for a non-template friend.
The question is whether the non-template function is part of the
overload set. If so, it will be preferred to the template
version: non-template over template is a tie breaker in cases
where overload resolution otherwise finds two equally good
functions. If it's not part of the overload set, of course, it
can't be chosen, and all that is left is the template function.
Presumably, you have a declaration of the template function:
template< typename T >
unsigned int hashFunc( T const& ) ;
somewhere before the definition of class Hash. Otherwise, the
code doesn't even compile with g++ 4.0.2. If this is the case,
non-dependant name lookup binds the name hashFunc to this
template declaration at the point of definition of the template;
no later declarations are taken into account. So only the
template function is in the overload set.
Note: when I speak of the "template function" above, I mean the
specific instance chosen by template argument deduction. The
rules of template argument deduction actually do the intuitive
thing here. In fact, it's interesting to note that in the case
of taking the address of a function -- what is actually
happening here -- both template argument deduction and operator
overload resolution DO take the use into account. Given this,
one might think it more reasonable if the decision whether a
symbol was dependant or not also took this into account. The
problem, however, is that until it has bound the symbol to the
name of a function, or to the name of a function template, the
compiler cannot know whether it is taking the address of a
function or not.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]