From -3413519376491618863 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,ab08a3e89d74b8d7 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-05-06 00:54:02 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!kibo.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: "Garry Lancaster" Newsgroups: comp.std.c++ Subject: Re: Core Language Active Issue #329 Date: Mon, 6 May 2002 07:53:12 GMT Organization: ntlworld News Service Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: References: <3CD19D55.1050804@mail.com> X-Trace: mail2news.demon.co.uk 1020671597 mail2news:28161 mail2news mail2news.demon.co.uk X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 NNTP-Posting-Date: Sat, 04 May 2002 11:58:37 BST Lines: 72 Xref: archiver1.google.com comp.std.c++:11055 Hyman Rosen: > The comment on Core Language Active Issue #329 contains > a suggestion that functions defined in a friend function > declaration in a class template should be evaluated only > if used. But the point of the existing mechanism is to > force these functions into the enclosing namespace so > that they are available for overload resolution. It is > important that any change to this mechanism preserve the > intended behavior. > > For example, one can have a template with one type parameter > which defines all the relational operators for the type as > friends using operator<. Then the type itself can inherit from > the template, and the relational operators spring into being > for this type, without affecting any others. > > template struct relops { > friend bool operator==(const T &a, const T &b) > { std::cout << "Friend"; return !(a < b) && !(b < a); } > }; > struct me : relops > { > int x; > me(int x = 0) : x(x) { } > operator int() { return x; } > bool operator<(const me &o) { return x < o.x; } > }; > int main() > { > std::set mine; > me you(7); > mine.insert(you); > // The following should use the operator==(me,me) friend, > // not the conversion to int followed by operator==(int,int) Actually it won't use either. The default comparison operator for std::set is <, not ==. Equality is just defined as: comp( lhs, rhs ) == false && comp( rhs, lhs ) == false > std::find(mine.begin(), mine.end(), you); > } For what it's worth I think that the proposed resolution to #329 is OK. The current rule is counter-intuitive: member functions are only defined when "referenced in a context that requires the function definition to exist" [14.17.1/2] and I don't see why friend functions should be different. We need to make the distinction between declaration and definition. It is right that the declaration is visible and therefore considered for overload resolution, even if the function instantiation has not yet been defined. (Of course, if it is selected to be called, as the best fit overload, the instantiation will then be defined.) This should sort out the issue I think you were getting at. Kind regards Garry Lancaster Codemill Ltd Visit our web site at http://www.codemill.net --- [ 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 ]