From 4637445414591349924 X-Google-Thread: f78e5,d9fe358a73c69991 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!proxad.net!newsfeed.stueberl.de!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: hinnant@metrowerks.com (Howard Hinnant) Newsgroups: comp.std.c++ Subject: Re: Should failure to instantiate a function template abort compilation during overload resolution? Date: Thu, 11 Aug 2005 14:38:54 GMT Organization: Metrowerks Lines: 45 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <1123485075.096196.242990@g44g2000cwa.googlegroups.com> <42F9CFA3.4000006@cs.york.ac.uk> NNTP-Posting-Host: news.news.demon.net X-Trace: news.demon.co.uk 1123771357 20566 158.152.254.254 (11 Aug 2005 14:42:37 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 11 Aug 2005 14:42:37 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: MT-NewsWatcher/3.4 (PPC Mac OS X) X-Greylisting: NO DELAY (Relay+Sender autoqualified); processed by UCSD_GL-v2.1 on mailbox8.ucsd.edu; Thu, 11 August 2005 06:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id j7BEcsAX029554; Fri, 12 Aug 2005 00:38:54 +1000 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Thu, 11 Aug 2005 09:52:52 EDT X-Delivered-To: std-c++@ucar.edu X-Spamscanner: mailbox8.ucsd.edu (v1.6 Aug 4 2005 15:27:38, 0.0/5.0 3.0.4) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsgroups: comp.std.c++ X-MailScanner: PASSED (v1.2.8 96498 j7BDr0kq003265 mailbox8.ucsd.edu) Xref: g2news1.google.com comp.std.c++:1765 In article <42F9CFA3.4000006@cs.york.ac.uk>, caj@cs.york.ac.uk (chris jefferson) wrote: > Howard Hinnant wrote: > > In article <1123485075.096196.242990@g44g2000cwa.googlegroups.com>, > > wuyongwei@gmail.com wrote: > > > > CodeWarrior is experimenting with an enable_if-like return type on > > std::distance so that this overload will not participate in overload > > resolution if InputIterator isn't an iterator. Your example on our > > implementation will compile and set d == 2 at runtime. > > > > I had thought about using a similar technique on many other of the > functions in std::, for example to stop functions matching if they are > given incorrect iterator types, which should hopefully lead to better > (or at least much smaller) error messages. However I was under the > impression that all functions had to have exactly the same signiture as > they do in the standard? Am I wrong? I'm not positive. If my modification can cause conforming programs to behave differently than they're supposed to, you're right. Else I get away with it under the as-if rule. As far as I know I'm getting away with it under as-if. I've simply taken a few non-conforming programs that have undefined behavior and assigned them behavior my customers may find more pleasing. But now that I've publicly stated that, I'm sure someone will show me a counter example. Like I said, it is an experiment. :-) And in the final analysis my customers will let me know whether or not it is successful. Because this is an experiment, I haven't treated all of the std::algorithms this way. I picked on std::distance because of my perception that it was especially vulnerable to the problem reported by the OP. -Howard --- [ 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 ]