"Edward Diener No Spam" <eldiener_no_spam_here@earthlink.net> wrote in
message news:tu1hf.4620$wf.1023@newsread3.news.atl.earthlink.net...
> 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++.

I expected it to say "f: unknown identifier".

Chris


---
[ 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:
[snip]
> What is the motivation of not associating struct A with parameters b and c?
> Visual C++ 8.0 does and says 'cannot convert to 'int'' in spite of the
> standard.  I know that it is not prescribed by 3.4.2/2; I would like to know
> *why* it is not.

It may be that no one thought to include enclosing classes of bases in
the list of associated classes, or they thought it was unnecessary. Do
you have a non-artificial use case? If not, the question is rather
academic...

Tom

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

Uzytkownik "Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> napisal w
wiadomosci news:dtrhf.5179$S6.86530@twister2.libero.it...
> "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

It has been fixed.  The actual error message is 'f is inaccessible' which is
not very appropriate but it is better than nothing.

> OP is irrelevant: ADL is not even involved because f is found during
> normal lookup.

No, it is not.

>
>> 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?
>

I cannot, this is a theoretical question.  Could you argue that public
member functions of the base class should be inaccessible if the length of
the inheritance chain is greater than 86?  I am sure no counterexample to
this rule can be provided.  I just find it more logical the Microsoft way,
i.e. ADL recursive up the nesting levels.

Chris


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

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?
Visual C++ 8.0 does and says 'cannot convert to 'int'' in spite of the
standard.  I know that it is not prescribed by 3.4.2/2; I would like to know
*why* it is not.

Chris


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