From -6414133350728353422 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,ab08a3e89d74b8d7 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-05-08 12:55:01 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: Wed, 8 May 2002 19:53:57 GMT Organization: ntlworld News Service Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: References: <3CD19D55.1050804@mail.com> <3CD6A00D.2080502@mail.com> X-Trace: mail2news.demon.co.uk 1020887645 mail2news:27674 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: Wed, 08 May 2002 18:18:12 BST Lines: 78 Xref: archiver1.google.com comp.std.c++:11114 > Garry Lancaster wrote: > > Actually it won't use either. The default comparison > > operator for std::set is <, not ==. Hyman Rosen: > I'm calling std::find on a sequence. > 25.1.2 says that operator== is used. Oops. Right you are. Of course, normally you wouldn't use that overload of std::find on a set because std::set::find is more efficient. But still, I should have read what you actually wrote ;-) > > 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. > > The declaration itself can involve the template > parameters in such a way that it is legal for some > types and illegal for others. Could you explain what you mean by that? Are you referring to the fact that pass-by-value and return- by-value require a copy ctor? If so, isn't that a separate issue, and one that affects all functions? > I see no reason to > change the behavior away from what exists currently. A couple of reasons: 1. It means that the body of a function template that is never called is instantiated. I could be wrong but I think this is the only way this can happen unless using explicit instantiation. As I already mentioned, that is inconsistent with member function behaviour, but it's also inconsistent with the behaviour of non-friend non-member functions. 2. According to the write-up in issue 329, many compilers do it this way anyway so we'd be standardising existing practice. > If you must instantiate a template for a type for > which the friends will be incorrect, write a > specialization which doesn't contain them. Of course. But by having to write your own specialization you lose out on the re-use advantage of the generic class template. Perhaps you could give some reasons why the behaviour should remain as currently specified? Previously you wrote: "the point of the existing mechanism is to force these functions into the enclosing namespace so that they are available for overload resolution." But as I pointed out, that just requires the declaration to be visible, not the definition. In either case, your example code would have the behaviour you wish it to have. 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 ]