Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!news.albasani.net!.POSTED!not-for-mail From: gayan.harutyunyan@googlemail.com Newsgroups: comp.std.c++ Subject: Re: Unqualified name lookup Date: Wed, 26 Sep 2012 17:09:53 -0700 (PDT) Organization: unknown Lines: 255 Sender: std-cpp-request@vandevoorde.com Approved: james.dennett@gmail.com Message-ID: <8083df1d-5981-4b57-901f-b66bd3559c19@googlegroups.com> References: NNTP-Posting-Host: Cqo/OCq/cwuKUciRQ8vlabRmdpKyj8yWo6knLT8bBeQ= Content-Type: text/plain; charset=ISO-8859-1 X-Trace: news.albasani.net 3x5JU4wWb+5UeEtpWDHuREp9ijGYX3inurL78C8HehGfh0WaYazNfEzrrDVIe+v4n4TppvgZPHDUQ+sHqKcwEA== X-Complaints-To: abuse@albasani.net NNTP-Posting-Date: Thu, 27 Sep 2012 00:09:56 +0000 (UTC) X-Mailer: Perl5 Mail::Internet v2.05 X-Submission-Address: std-cpp-submit@vandevoorde.com Cancel-Lock: sha1:EFW+IPG4B8mlR3MTj/GyQtbN5Xg= X-Original-Date: Wed, 26 Sep 2012 13:04:19 -0700 (PDT) Xref: csiph.com comp.std.c++:547 On Sunday, December 4, 2011 2:23:41 PM UTC+4, Francis Glassborow wrote: > On 03/12/2011 16:24, koszal wrote: > > > > > > Hello all, > > > > > > I'm looking for some explanation of the unqualified name lookup > > > specified in the spec. > > > In particular there is an example in the point 3.4.1$3: > > > > > > typedef int f; > > > namespace N { > > > struct A { > > > friend void f(A&); > > > operator int(); > > > void g(A a) { > > > int i = f(a); // f is the typedef, not the friend > > > // function: equivalent to int(a) > > > } > > > }; > > > } > > > > > > and the text below it says: > > > [1] "because the expression is not a function call, the argument- > > > dependent name lookup (3.4.2) does not apply and the friend function f > > > is not found". > > > > > > Why the expression 'f(a)' is not a function call? Could somebody > > > explain to me how compiler infers here that this is a functional style > > > cast and not a function call? > > > > > > I just can't wrap my head around this - especially if I take into > > > account that the note above this example says: > > > [2] "For purposes of determining (during parsing) whether an > > > expression is a postfix-expression for a function call, the usual name > > > lookup rules apply. The rules in 3.4.2 have no effect on the syntactic > > > interpretation of an expression." > > > > > > My reading of this results in the following expectations for this > > > particular example: > > > 1. var 'i' is initialized by the expression 'f(a)' > > > 2. there is an ambiguity since 'f(a)' could be a function style cast > > > or a function call > > > 3. 'f' should be looked up for what it is and friend function is found > > > 4. ambiguity is resolved and this should be treated as a function call > > > 5. there is a typing error which should be reported by the user > > > Could anybody fix this list for me - most suspected is point 3 but the > > > text [1] says that is not a function call so maybe point 2 is also > > > wrong? > > > > > > I'd appreciate any explanations > > > > > > Best regards > > > Andrzej Ostruszka > > > > > > > > > > It was decided (in order to preserve some important techniques) that a > > friend function would not be visible unless > > 1) the function was declared at namespace scope (i.e. the friend > > declaration was insufficient) > > > > or > > > > 2) the call was a fully qualified call effectively bringing the class > > scope into the search list. > > > > Now in the code above the definition of g() is treated as if it had > > been written at namespace scope as: > > > > void A::g(A a){ > > int i = f(a); > > } > > > > The only f visible at this scope is the typedef and there is nothing > > in this relocated code to trigger a search in the scope of A. > > > > I know it seems odd but that is about par for the course when dealing > > with name lookup rules :( > > > > > > > > -- > > [ comp.std.c++ is moderated. To submit articles, try posting with your ] > > [ newsreader. If that fails, use mailto:std-cpp-submit@vandevoorde.com ] > > [ --- Please see the FAQ before posting. --- ] > > [ FAQ: http://www.comeaucomputing.com/csc/faq.html ] @Francis , let me not agree with you, concerning the function g "> Now in the code above the definition of g() is treated as if it had > > been written at namespace scope as: > > > > void A::g(A a){ > > int i = f(a); " in the following small example there is a difference case 1 class X{ public: X& operator% (const X&) { std::cout << "member fun\n"; return *this; } void f() { X& a = *this; a % 1; /* error */ } }; X& operator%( X& a, int) { std::cout << "global fun\n"; return a; } main () { X x; x.f(); } in this case compiler complains , in function f "a%1"'s look-up ends with member function and compiler detects argument mismatch while in the following case 2 class X{ public: X& operator% (const X&) { std::cout << "member fun\n"; return *this; } void f(); }; X& operator%( X& a, int) { std::cout << "global fun\n"; return a; } void X::f() { X& a = *this; a % 1; } main () { X x; x.f(); } compiler matches on the non-member function -- [ comp.std.c++ is moderated. To submit articles, try posting with your ] [ newsreader. If that fails, use mailto:std-cpp-submit@vandevoorde.com ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]