From -1392572640067387281 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,bcce9f6c39d8ade1 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1994-09-25 19:23:14 PST Newsgroups: comp.std.c++ Path: bga.com!news.sprintlink.net!pipex!sunic!trane.uninett.no!eunet.no!nuug!EU.net!uunet!news.cygnus.com!news!jason From: jason@cygnus.com (Jason Merrill) Subject: Re: Some iostream strangeness In-Reply-To: rfg@netcom.com's message of Sun, 25 Sep 1994 22:06:07 GMT Content-Type: text/plain; charset=US-ASCII Message-ID: Sender: news@cygnus.com Nntp-Posting-Host: deneb.cygnus.com Organization: Cygnus Support, Mountain View, CA References: <9426404.25042@mulga.cs.mu.OZ.AU> Mime-Version: 1.0 Date: Mon, 26 Sep 1994 02:14:36 GMT Lines: 53 >>>>> Ronald F Guilmette writes: > In article jason@cygnus.com (Jason Merrill) writes: >>>>>>> Fergus Henderson writes: >>> But I still don't see how this explains the behaviour described by >>> the original poster, since `cin >> (void *)0' should give similar >>> results to `cin >> 0' anyway. >> It explains the behavior because cin >> NULL is ambiguous and >> cin >> 0 is not; cin >> NULL can match any of the several pointer >> extractors, whereas cin >> 0 unambiguously matches the int extractor. > Ummm... But shouldn't the int extractor be declared to take a parameter > of type `int&'? It is. > If so, then why does your int extractor allow a (non-lvalue) literal as > its argument? *As I said earlier in this thread*, it doesn't. Not in pedantic mode, anyway. The compiler selects istream::operator>>(int&), but complains when it tries to call it. Admittedly, as of the January WP the function should be rejected at the point of selecting viable functions: 13.2.3.1.4 Reference binding [over.ics.ref] 2 A standard conversion sequence cannot be formed if it requires binding a reference to non-const to an rvalue (except when binding an implicit object parameter; see the special rules for that case in _over.match.funcs_). This means, for example, that a candidate func- tion cannot be a viable function if it has a non-const reference parameter (other than the implicit object parameter) and the corre- sponding argument is a temporary or would require one to be created to initialize the reference (see _dcl.init.ref_). But the result in this case is the same. Out of curiosity, do any compilers currently implement this rule? In other words, do they accept code like void f (int&); void f (int, int=0); main() { f(1); } ? g++ 2.6.0, Cfront 3.0.1 and xlC 1.3 all complain that the call is ambiguous. Jason