This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/14364] Function should depend on template
- From: "giovannibajo at libero dot it" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 1 Mar 2004 14:55:56 -0000
- Subject: [Bug c++/14364] Function should depend on template
- References: <20040301143212.14364.ben@zeus.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From giovannibajo at libero dot it 2004-03-01 14:55 -------
First, please check changes.html, there is an entry about GCC implementing the
standard lookup rules in templates which you might find interesting.
Both "CalcHash" and "::CalcHash" are non-dependent expression, which are looked
up at *definition* time, so much before the CalcHash function was defined.
1) "CalcHash" is a unqualified-id. In templates, there is a special form of
Koenig lookup that is deferred to instantiation time if any of the argument is
dependent. In this case, the type of the argument is K (template parameter), so
the compiler remembers that no function has been found at definition time, but
waits until instantiation time.
Then, when instantiation happens, it performs a Koenig lookup using the
associated namespaces of the template parameters. It finds out that K = Bar,
and Bar is a member of the global namespace, so it looks within the global
namespace and finds a CalcHash declaration. Since at definition time no
declaration was found, there is no ambiguity, and CalcHash is called.
2) "::CalcHash" is a qualified-id. Koenig lookup is performed only on function
calls made through unqualified-ids. This of course happens because if you
qualified the function, it means you're explicitally asking the compiler to
look into a specific namespace, so you don't need Koenig lookup. Now, the
problem is that, at definition time, there is no CalcHash available. Since
there is nothing to do at instantiation time, the compiler emits a diagnostic
saying that it cannot find a valid function declaration.
In the end, the behaviour of GCC 3.4 is strictly standard conforming as far as
I can tell. GCC 3.3 used to defer everything at instantiation time, hence the
bug (it was incorrectly accepting your code).
--
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14364