From 2534315643661193273 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,cbf1693e6ece180b X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-12-15 19:37:14 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!news-FFM2.ecrc.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: deepblue57x@yahoo.co.nz (Graeme Prentice) Newsgroups: comp.std.c++ Subject: Re: template friends Date: Tue, 16 Dec 2003 03:37:08 +0000 (UTC) Lines: 100 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <4MpCb.70557$Qn2.26313@newssvr25.news.prodigy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: mail2news.demon.co.uk 1071545828 2943 10.0.0.1 (16 Dec 2003 03:37:08 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Tue, 16 Dec 2003 03:37:08 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.12) id 1AW61B-0000lK-00 for mail2news@news.news.demon.net; Tue, 16 Dec 2003 03:37:06 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id OAA16588; Tue, 16 Dec 2003 14:36:41 +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++@ucar.edu X-Newsgroups: comp.std.c++ X-Orig-NNTP-Posting-Host: 203-79-93-190.tnt11.paradise.net.nz (203.79.93.190) X-Orig-X-Trace: news.uni-berlin.de 1071482871 4436415 203.79.93.190 ([98036]) X-Newsreader: Forte Agent 1.93/32.576 English (American) X-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_01,MAILTO_TO_REMOVE,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Xref: archiver1.google.com comp.std.c++:690 On Sat, 13 Dec 2003 03:16:18 +0000 (UTC), cpdaniel_remove_this_and_nospam@mvps.org.nospam ("Carl Daniel") wrote: >Consider the following code: > >// >template class C; > >template T1 f(const C&); // 1 >template T f(const C&); // 2 > >template class C >{ > private: T m_t; > > friend T f(const C&); // a > friend T f(const C&); // b > friend T f<>(const C&); // c >}; > >template >T f(const C& ct) >{ > return ct.m_t; >} > >template >T1 f(const C& ct) >{ > return ct.m_t; >} > >void test() >{ > C ci; > f(ci); > f(ci); >} > >// > >According to Comeau online, any of the three friend declarations (a/b/c) >grants friendship to both template functions (1/2). > >I would intuitively expect that 'a' should grant friendship to '1', 'b' >should grant friendship to '2' and 'c' should grant friendship to both '1' >and '2'. > >Is Comeau right? (It usually is!) yep, except that both function calls to f() from test() call the version of f() that has two template parameters, just as all 3 friend declarations refer to the two template parameter version of f(). (If you purchased the Comeau compiler (it's cheap) you could execute the code to see this). 14.8.1 para 2 allows trailing template arguments to be omitted, including in a friend declaration. Partial ordering finds the two template parameter f() to be more specialised because decuction from it into the one-template-parameter f() succeeds but fails in reverse because the return type T1 can't be deduced. Defect report 214 proposes to alter partial ordering to allow for some return type cases - it says that for partial ordering purposes, a template parameter may remain without a "value" if it is not used in the types being used for partial ordering. In your example, the return type T1 is not used in the types being used for partial ordering so according to defect report 214, the function calls and friend declarations are ambiguous - just like VC7.1 says :-) - I guess VC7.1 is ahead of the times. Here's the example from the defect report that shows how the template parameter that appears only in the return type is ignored template T f(int); // #1 template T f(U); // #2 void g() { f(1); // Calls #1 } The intention is that the int function can be favoured by partial ordering because it is "obviously" more specialised even though deduction fails in both directions because the return type can't be deduced. I have a feeling it will be a while before defect report 214 becomes part of the standard. I asked some questions on here a while ago about how it proposes to drop references and CV qualifiers during partial ordering but no-one responded. Graeme --- [ 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 ]