Re: Bug in g++?
Re: Bug in g++?
- Subject: Re: Bug in g++?
- From: Steve Checkoway <email@hidden>
- Date: Fri, 06 Oct 2006 16:13:12 -0700
Howard Hinnant wrote:
On Oct 6, 2006, at 3:06 PM, Steve Checkoway wrote:
What you said makes sense. The only problem is that by making Read()
not virtual, the problem goes away. FromStack() is still in the
LuaHelpers namespace, from what you said, it should still be looking
for it at template definition time.
Ah, the difference there is that if a member function of a template
class is virtual, it is allowed to be instantiated (and everyone does).
If it isn't virtual, it is required not to be instantiated unless used.
So to see the error with read being non-virtual you have to:
Okay, I see the error there as well now.
Also, in g++ 4.0 (but not 4.1), this change works
void Read()
{
using namespace LuaHelpers;
T x;
FromStack(x);
}
Surely at least two of the implementations of g++ 3.3, (3.4-4.0), and
4.1 must be wrong.
My best understanding is that 4.0 is in error in accepting this fix.
FromStack(x) is bound at instantiation time (also known as phase 2).
Ordinary lookup happens in the context of the definition, not the
context of the instantiation and finds the first 3 FromStack's. ADL
then tries to find some more matches and uses both the definition
context and the instantiation context, but only searches the global
namespace, and so doesn't find the 4th FromStack.
What is the rationale for doing the lookup in the context of the
definition when an explicit namespace is specified? It would seem to
limit the usefulness of templates. Why wouldn't it do ADL using the
definition context and then the instantiation context in the specified
namespace?
If that spins your head somewhat, don't feel bad. My head hurts right
now too. :-) If you want to explore this in the standard it is 14.6.4.2.
I'm doing that now. I guess I see that in the standard. 14.6.4 says
"In resolving dependent names, names from the following sources are
considered:
-- Declarations that are visible at the point of definition of the template.
-- Declarations from namespaces associated with the types of the
function arguments both from the instantion context and from the
definition context."
Okay, that seems reasonable. Then in 14.6.4.2, it says,
"For a function call that depends on a template parameter, if the
function name is an unqualified-id but not a template-id, the canidate
functions are found using the usual lookup rules (3.4.1, 3.4.2) except that:
-- Blah.
-- Blah.
If the call would be ill-formed or would find a better match had the
lookup within the associated namespaces considered all function
declarations with external linkage introduced in those namespaces in all
translation units, not just considering those declarations found in the
template definition and template instantiation contexts, then the
program has undefined behavior."
Unless I'm mistaken, LuaHelpers::FromStack is not an unqualified-id. so
the first part doesn't apply (hence the blahs).
It's the second part that seems to apply but it makes no sense as to why
this would be the case. To quote the developer who filed the debian bug
report, "It's ludicrous that 'foo(x)' in the template will use overloads
of foo() declared later, but 'x::foo' doesn't do the exact same thing."
This isn't really related to Xcode any longer. Is there a better place
to discuss this? <http://lists.apple.com/mailman/listinfo> doesn't seem
to contain a compiler list (as was noted on perfoptimization-dev earlier
this week).
--
Steve Checkoway
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden