"Edward Diener No Spam" <eldiener_no_spam_here@earthlink.net> wrote in
Christopher Yeleighton wrote:
>>>Visual C++ 8.0 does and says 'cannot convert to 'int'' in spite of the
>>>standard.
>>
>>The function 'f' takes an 'int' as its only parameter. What do you expect
>>Visual C++ 8.0 to say ? A friend function does not have a hidden 'this' in
>>its function prototype. I think you are confused by what 'friend' means in
>>C++.
>
> I expected it to say "f: unknown identifier".
>

This answer is technically correct, but its terseness is hardly helpful
to those who haven't fully grasped the point of the discussion. Not
everybody posting on this newsgroup is a guru, you know. I don't pretend
to be a guru either, but please allow me to be more verbose.

The key point is that the friend declaration of f does not introduce f
in the global namespace, so f is not found during normal lookup but only
through argument-dependent lookup (ADL). For example:

// EXAMPLE (1)

struct A
{
  friend void f(int);
};

void bar()
{
  f(0); // error: f is undefined
}

The parameter 0, being an int, has no associated namespaces or classes,
so ADL does not kick-in and f is not found.

// EXAMPLE (2)

struct A
{
  friend void f(int);
};

void bar()
{
  A a;
  f(a); // error: no conversion from A to int
}

In this case, ADL makes the compiler look into the scope of class A so f
*is* found. Unfortunately f takes a int, so the compiler tries to
convert A to int, but in vain.

Now, let's get to the two OP's points.

> Visual C++ 8.0 does and says 'cannot convert to 'int'' in spite of the
> standard.

Clearly VC++ 8.0 is buggy, but the bug is probably different from what
you think. I know that VC++ 7.1 *is* buggy, because it introduces f in
the global namespace in spite of the standard. You can check this by
trying to compile Example (1) above: you will get no error. I guess this
bug just hasn't been fixed in v8.0 out of fear for backward
incompatibility. Notice that in this case the convoluted example in the
OP is irrelevant: ADL is not even involved because f is found during
normal lookup.

> What is the motivation of not associating struct A with parameters b and c?
> I know that it is not prescribed by 3.4.2/2; I would like to know
> *why* it is not.

Frankly I don't know, but three levels of class nesting are such a rare
occurrence that I don't feel it would add a big value to change that. As
for the "enclosing" class of a base, it might as well be a completely
unrelated class, so it looks natural to me not to associate with it.

Now, it's your turn: why do you think it should be different? Could you
provide a non-trivial use case?

Regards,

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Christopher Yeleighton wrote:
> The following code is ill-formed by 3.4.2/2:
>
> struct A {
>
> struct B { struct C; };
>
> friend void f(int);
>
> };
>
> struct B1: public A::B { };
>
> void fun(A::B::C &c) { f(c); }
>
> void fun(B1 &b) { f(b); }
>
>
>
> What is the motivation of not associating struct A with parameters b and c?

Look at the function prototype for 'f'. Does it say anything about
taking struct A as a parameter ?

> Visual C++ 8.0 does and says 'cannot convert to 'int'' in spite of the
> standard.

The function 'f' takes an 'int' as its only parameter. What do you
expect Visual C++ 8.0 to say ? A friend function does not have a hidden
'this' in its function prototype. I think you are confused by what
'friend' means in C++.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]