From 7241885075250557749 X-Google-Thread: f78e5,6044e1103a193178 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news2.volia.net!newsfeed01.sul.t-online.de!t-online.de!newsfeed.vmunix.org!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: AlbertoBarbati@libero.it (Alberto Ganesh Barbati) Newsgroups: comp.std.c++ Subject: Re: associated namespaces do not comprise enclosing classes of the base class Date: Fri, 25 Nov 2005 01:04:25 GMT Organization: [Infostrada] Lines: 90 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: news.demon.co.uk 1132880673 27951 158.152.254.254 (25 Nov 2005 01:04:33 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Fri, 25 Nov 2005 01:04:33 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Scanned: with antispam and antivirus automated system at libero.it X-Greylisting: DELAYED for 00:02:26; processed by UCSD_GL-v2.1 on mailbox7.ucsd.edu; Thu, 24 November 2005 14:53:23 -0800 (PST) X-Accept-Language: en, it X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Path: comp-std-cpp-robomod!not-for-mail X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id jAP14PHd007037; Fri, 25 Nov 2005 12:04:25 +1100 (EST) X-NNTP-Posting-Date: Thu, 24 Nov 2005 23:50:49 MET X-Delivered-To: std-c++@ucar.edu X-Spamscanner: mailbox7.ucsd.edu (v1.6 Aug 4 2005 15:27:38, 0.0/5.0 3.0.4) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsgroups: comp.std.c++ X-MailScanner: PASSED (v1.2.8 75174 jAOMrL4m081515 mailbox7.ucsd.edu) Xref: g2news1.google.com comp.std.c++:2596 "Edward Diener No Spam" 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 ]