From 2496916022287648254 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,c42fc9ad8a4a8a45 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-01-21 15:54:48 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: llewelly.@@xmission.dot.com (llewelly) Newsgroups: comp.std.c++ Subject: Re: Lookup for operators in expressions 13.3.1.2 Date: Tue, 21 Jan 2003 23:54:43 +0000 (UTC) Organization: The Illusory Sorting Algorithm Lines: 125 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <86lm1ejhm1.fsf@Zorthluthik.foo> References: <86fzrnl8yj.fsf@Zorthluthik.foo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: mail2news.demon.co.uk 1043193283 5390 10.0.0.1 (21 Jan 2003 23:54:43 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Tue, 21 Jan 2003 23:54:43 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.05) id 18b8E5-0001On-00 for mail2news@news.news.demon.net; Tue, 21 Jan 2003 23:54:41 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id KAA01201; Wed, 22 Jan 2003 10:54:36 +1100 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ncar.ucar.edu X-Newsgroups: comp.std.c++ X-NNTP-Posting-Date: Tue, 21 Jan 2003 21:55:05 +0000 (UTC) X-User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 X-MailScanner: PASSED (v1.2.7 61306 h0LLxl2D094872 mailbox1.ucsd.edu) X-Spam-Status: No, hits=-10.3 required=5.0 tests=EMAIL_ATTRIBUTION,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT version=2.41 Xref: archiver1.google.com comp.std.c++:17366 gp1@paradise.net.nz (Graeme Prentice) writes: F> On Mon, 20 Jan 2003 23:53:22 +0000 (UTC), llewelly.@@xmission.dot.com > (llewelly) wrote: > > >gp1@paradise.net.nz (Graeme Prentice) writes: > > > >> Regarding the expression a @ b where @ is an operator such as << and a > >> has type T1 > >> > >> 13.3.1.2 para 3 bullet 1 says Now I notice that 13.3.1.2/3 begins with 'For a unary operator ...' and 13.3.1.2/5 is 'For all other operators, no such restrictions apply' Maybe 13.3.1.2/3 does not apply to the example you present below. However I believe: class c1; extern c1 o1; void operator++(c1&); int main() { ++o1; } raises the same question, and (I think) falls under 13.3.1.2/3 . This code compiles with no errors using gcc 3.2.1. I put: class c1 { public: void operator++(){} }; c1 o1; void operator++(c1&){} in a second translation unit, and it linked without errors. Some tracing couts revealed the non-member void operator++ was used. I don't know what the standard thinks of this code. If the set of member canidates is empty when the type is incomplete, the meaning of a simple expression may change depending on whether the class definiton is availible. However, requiring the operator to be looked up in the scope of the class in this example seems to require postponing overload resolution to link time. I don't imagine implementors would care for that, especially those who support shared libraries. > >> > >> If T1 is a class type, the set of member candidates is the result of the > >> qualified lookup of T1::operator@ (13.3.1.1.1); otherwise, the set of > >> member candidates is empty. > >> > >> Does this mean that the class definiiton of T1 has to be visible or does > >> it mean that if the lookup fails for whatever reason, the set of > >> candidates is empty. > >> > >> For example if you write cout << "hello"; does the class definition for > >> the type of cout have to be visible. > > > >3.4.3.1/1 (Qualified name lookup, Class members): > > > ># If the nested-name-specifier of a qualified-id nomintates a class, > ># the name specified after the nested-name-specifier is looked up in > ># the scope of the class (10.2) ... [sniped] > > > >The paragraph then continutes to specify 3 exceptions, applying to > > destructors, conversion-type-ids, and template-ids, none of which > > seem relevant to your question. > > > >So combining 13.3.1.2/3 with 3.4.3.1/1, I think the operator will be > > looked up in the scope of the class, whether it is 'visible' or > > not. > > > I'm not sure I understand you. If the class definition is not > visible I failed to relate 'not visible' to 'incomplete'; I didn't understand *you*. > then it's an incomplete type so can't be looked up in the scope of the > class. For the following code, the Borland compiler gives a compile > time error (undefined structure c1), Comeau 4.3.0.1 gives a > catastrophic failure (seems to be a problem in the Borland backend, so > the "front end" probably thinks it's valid) and GCC 3.2 compiles with no > errors. If this code is intended to be valid, I think 13.3.1.2 should > say that if the class T1 is an incomplete type then the set of member > candidates is empty - or else it should say that T1 must be a complete > type. The way 13.3.1.2 is currently written leaves it open to > interpretation IMO. Maybe you should file a defect report. Prior to your post, I would have assumed that if T1 was incomplete, the set of member candidates would be empty. I don't see that in the standard, however. > Since some compilers treat it as valid code, it's > probably best to allow an incomplete type, to avoid breaking existing > code, if nothing else. I agree. However I'd really like to hear from someone (in addition to you) who understands overloading better than me. > class c1; > extern c1 o1; > void operator<<( c1&, int ); > > int main() > { > o1 << 23; > } [snip] --- [ 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 ]