From 7856401426911461379 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,7eaa8faac8da5016 X-Google-Attributes: gidf78e5,public From: "Darin Adler" Subject: Re: Defect Report: member == in container iterators considered harmful Date: 1999/08/20 Message-ID: <7pi5us$3153@enews3.newsguy.com>#1/1 X-Deja-AN: 515039306 Content-Transfer-Encoding: 7bit Approved: Fergus Henderson References: <7p4nj8$n3u@enews4.newsguy.com> <37B95B96.7F37@wanadoo.fr> <7pcoa8$2kf0@enews2.newsguy.com> <37BABF02.3EBE@wanadoo.fr> <7pf1b2$ls8@enews3.newsguy.com> <37BC0B5B.4AD8@wanadoo.fr> X-Original-Date: Thu, 19 Aug 1999 17:02:36 -0700 Content-Type: text/plain; charset="US-ASCII" X-Complaints-To: news@news.unimelb.edu.au X-Trace: izvestia.its.unimelb.edu.au 935139454 18790 128.250.29.17 (20 Aug 1999 08:57:34 GMT) Organization: http://extra.newsguy.com X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUAN70YW+EDnX0m9pzZAQFIsgF6AwUUNudM9MkcCIKXYhOn6x8oeQNkCopg d2YiwwIsKBNinToO886axggSjY+ebkyN =FiAn Mime-Version: 1.0 NNTP-Posting-Date: 20 Aug 1999 08:57:34 GMT Newsgroups: comp.std.c++ > Darin Adler wrote: >> I meant to propose a non-member function, which can be a friend if >> necessary. As I understand it, the friend function above *is* a non-member >> function. Valentin Bonnard wrote: > Not really. It isn't a member, it isn't a normal global > function, it's something completely magical, a friend. Before your messages in this thread, I had understood that "friend" was a relationship between a class and a function, rather than a special category of function. But you're saying here that a friend function is a special kind of function, not a non-member function which has been granted special privileges. I thought that a non-member function that was not a friend would work. But it now seems that a friend is required. Original code: bool operator ==(const const_iterator& rhs) const {return cur_ == rhs.cur_;} Friend function: friend bool operator ==(const const_iterator& lhs, const const_iterator& rhs) {return lhs.cur_ == rhs.cur_;} Non-friend function attempt: bool _equal(const const_iterator& rhs) const {return cur_ == rhs.cur_;} [...] template bool operator==(const list::const_iterator& lhs, const list::const_iterator& rhs) { return lhs._equal(rhs); } But argument deduction won't work on the above attempt. Perhaps this is what you originally meant when you said that deduction won't work. It still seems to me that someone could make const_iterator be a non-nested class with a library-hidden name and just have the typedef inside the class. Like this: template class _list_const_iterator { [...] bool _equal(const _list_const_iterator & rhs) const {return cur_ == rhs.cur_;} [...] }; template class list { [...] typedef _list_const_iterator const_iterator; [...] }; template bool operator==(const _list_const_iterator& lhs, const _list_const_iterator& rhs) { return lhs._equal(rhs); } With this design the operator== could be a standard non-member function template. So it seems that there's no reason to demand a friend function. On the other hand, if only a friend function works, it still seems that my DR was correct. Because the standard would demand a non-member function that works, and if the only kind that would work is a friend, then implementers will have to use a friend. If an implementer discovers a way to make it work properly without using a friend function, that's fine as well! >> Can't a non-member function be a friend function? > > Of course it can. > > I just wanted to point out that: > - you did something (you changed your library code) > - you wrote some other thing in the DR, which makes > your DR proposed solution incorrect Here's what I'd like to know: Do you still think the DR solution I proposed is incorrect? If so, why? If the standard is amended to require a non-member function, but the only kind of non-member function that will work is a friend, doesn't that mean that all implementers will have to use friend functions? Does the standard have to explicitly mention "friend" to be correct? Would a simple wording change make my DR solution correct, corresponding to the experiment I did on my copy of the library? Will you help me correct the DR and resubmit it? I don't care so much if I made a mistake -- I'm willing to admit it if I did. But I do care whether the DR is wrong or right. I'd like the DR to have a good chance for fair consideration, unless there's a flaw in it. And if there's a way I can amend it to be correct, I'd like to do that. I believe your original comment, saying that my suggested solution won't work, was passed on to the committee. I think this will unnecessarily reduce the chance of the defect report being accepted. I hope the committee gets to see our ensuing discussion as well. -- Darin --- [ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]