From -7781774199136641872 X-Google-Thread: f78e5,d9fe358a73c69991 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!border1.nntp.dca.giganews.com!local01.nntp.dca.giganews.com!nntp.speakeasy.net!news.speakeasy.net.POSTED!not-for-mail NNTP-Posting-Date: Thu, 11 Aug 2005 15:10:05 -0500 Return-Path: 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) Delivered-To: std-c++@ucar.edu From: Gabriel Dos Reis Newsgroups: comp.std.c++ Subject: Re: Should failure to instantiate a function template abort compilation during overload resolution? Organization: Integrable Solutions Message-ID: References: <1123485075.096196.242990@g44g2000cwa.googlegroups.com> <42F9CFA3.4000006@cs.york.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@nerim.net User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Approved: Fergus Henderson , moderator of comp.std.c++ X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Date: Thu, 11 Aug 2005 15:06:05 CST Lines: 47 NNTP-Posting-Host: 65.182.171.162 X-Trace: sv3-swYM9Ocm9TA9LGnccIDGN53XUuEWlXjofJChFslqHkmUSYBa4plwXRD+ALGSKf8fp55zaKJcZY2/Ns1!PTsfVU78mjP3Uv+RNYX7Zb+U7WSanxgQNLoCV+nDxTOAY56p7ugmCvqWA76KxQovX6bCg8tqxG9Z!P9jQaqqQl3N0ECn2VpOgY0erolHh79p0rx4= X-Complaints-To: abuse@speakeasy.net X-DMCA-Complaints-To: abuse@speakeasy.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.std.c++:1778 hinnant@metrowerks.com (Howard Hinnant) writes: | 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. A fundamental issue is that since users can add overloads of "distance" in std::, the issue is not solved only if you instruct them to code in a highly stylistic way (using exactly the same trick as you or similar), otherwise you would have just paper over a corner: any direct expression of the ideas run into the problem you're attempting to solve. | I've simply taken a few | non-conforming programs that have undefined behavior and assigned them | behavior my customers may find more pleasing. I don't believe the specific case under discussion invokes undefined behaviour . --- [ 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 ]