On Thursday 10 November 2005 16:37, Joerg Barfurth wrote:
> According to clause 14.6.4.2 of the standard that two-phase lookup works
> differently than your simplified paraphrase suggests:
>
> - the ordinary unqualified lookup considers only the definition context
> - argument-dependent lookup considers both definition and instantiation
> contexts
>
> In the example you gave above, the global namespace is searched again by
> argument-dependent lookup, so ::f(B*) is found in phase two. But in my
> case (and the UNO one) the argument dependent lookup only finds
> declarations in namespace NS..
>
> Note: In the UNO case the template lives in a namespace itself, which
> may or may not be identical to the namespace (NS). But that doesn't
> change anything, because this only affects the unqualified lookup.
>
> And of course the declarations of struct A and f(A*) is mere scaffolding
> in the example. Without them, the error still occurs only at the point
> of instantiation (but then there are no candidates functions for f).
> Actually the most hideous case is when A is a public base class of B,
> because in that case the instantiation of g<B> succeeds, but should call
> f(A*) instead of f(B*).
>
> BTW, I'm not entirely sure how the *qualified* lookup case (the ::f(t)
> call in the template definition) would behave. I have only the original
> standard at hand and here 14.6.2/1 and 14.6.4/1 seem to disagree.
>
> Of course all this becomes a real problem, because most C++ compilers
> never got this right (and g++ is only getting there recently).

Here is an answer from Richard (one of our gcc developers):

--- cut ---
This last message seems to be analyzing the problem correctly.  This
is what currently happens.  Whether this is really correct (change
unqualified function name lookup because of qualified parameter types)
is not really clear from the standard.
--- cut ---


I asked if there is any authority who could decide. Richard answered:

--- cut ---
Someone pointed out some defect-reports, namely DR164, DR197, DR213 and 
DR225.  But they don't clear my confusion.  You may want to track
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24795
to see if someone else than pinskia comes to some reasoning.
--- cut ---


-- 
Best Regards,

Petr Mladek
software developer
---------------------------------------------------------------------  
SuSE CR, s.r.o.                             e-mail: [EMAIL PROTECTED]
Drahobejlova 27                             tel:+420 296 542 373 
190 00 Praha 9                              fax:+420 296 542 374   
Czech Republic                              http://www.suse.cz/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to