From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5415 invoked by alias); 18 Nov 2004 23:43:28 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5385 invoked from network); 18 Nov 2004 23:43:24 -0000 Received: from unknown (HELO boden.synopsys.com) (198.182.44.79) by sourceware.org with SMTP; 18 Nov 2004 23:43:24 -0000 Received: from maiden.synopsys.com (maiden.synopsys.com [146.225.100.170]) by boden.synopsys.com (Postfix) with ESMTP id AE241DB8B; Thu, 18 Nov 2004 15:42:48 -0800 (PST) Received: from piper.synopsys.com (localhost [127.0.0.1]) by maiden.synopsys.com (8.9.1/8.9.1) with ESMTP id PAA16201; Thu, 18 Nov 2004 15:43:22 -0800 (PST) Received: (from jbuck@localhost) by piper.synopsys.com (8.11.6/8.11.6) id iAINhMs02482; Thu, 18 Nov 2004 15:43:22 -0800 X-Authentication-Warning: piper.synopsys.com: jbuck set sender to Joe.Buck@synopsys.com using -f Date: Thu, 18 Nov 2004 23:45:00 -0000 From: Joe Buck To: Ziemowit Laski Cc: gcc mailing list , Matt Austern Subject: Re: generalized lvalues Message-ID: <20041118154322.A32680@synopsys.com> References: <8AD5AEEF-3914-11D9-8BD2-000A95BCF344@apple.com> <852F83A5-39B9-11D9-8317-00039390FFE2@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <852F83A5-39B9-11D9-8317-00039390FFE2@apple.com>; from zlaski@apple.com on Thu, Nov 18, 2004 at 03:28:15PM -0800 X-SW-Source: 2004-11/txt/msg00649.txt.bz2 On Thu, Nov 18, 2004 at 03:28:15PM -0800, Ziemowit Laski wrote: > So, at least as far as Apple is concerned, it would be great if the > casts-as-lvalues functionality were retained in GCC. :-) Of course, if > the compiler is run in -strict/-pedantic/-ansi/whatever mode, it should > be free to reject this construct if it is not in the appropriate > standard. It's just that there are C/C++ usage idioms out there (as > non-standard as they may be) for which the lvalue cast is a better > semantic fit than any alternative. The main reason why cast-as-lvalue is bad news for C++ is its effect on overloading. Consider: void func(const Type&); void func(Type&); ... func((Type)expression); cast-as-lvalue causes the wrong overloaded function to be called. The user would expect the cast to produce a temporary, meaning that the const version is called; however, because of the extension, the non-const version is called. This is not a small matter; given a non-const reference we can normally be sure that we have a real object of the given type, that we can write that object, save its address, etc. With a non-const reference, it might be bound to a temporary. Notice that in the above example, the programmer had no idea that his or her code was affected by an extension. There are two versions of func and the compiler chooses the wrong one. We shouldn't require -ansi or -pedantic to make correct code work correctly; in the past, we just use them to reject more incorrect code. If you must retain this extension, then at minimum we would need to prevent cast-as-lvalue from modifying the type of the cast expression for the purposes of overloading; even though it's an lvalue for the purpose of assignment, it can't be treated as an lvalue for purposes of operator overloading. That might be tricky. > I'll attempt to address the various technical reasons for removing > lvalue casts in a separate e-mail. For the time being, though, I just > wanted to express a partisan viewpoint on the issue. :-) > > Thanks, > > --Zem > -------------------------------------------------------------- > Ziemowit Laski 1 Infinite Loop, MS 301-2K > Mac OS X Compiler Group Cupertino, CA USA 95014-2083 > Apple Computer, Inc. +1.408.974.6229 Fax .5477