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                      ]

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


--
[ 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                      ]

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                      ]